3 ms·

I really like this. The only thing that kinda threw me off a bit was putting the partials in the /views/sync/resource/ folder. Feels a bit non-RESTy. I imagin

I really like this. The only thing that kinda threw me off a bit was putting the partials in the /views/sync/resource/ folder. Feels a bit non-RESTy. I imagine, for a sufficiently complex app that sync folder will become a bit messy - although, I guess it's like the 'layout' folder. That's just me being nitpicky though. This is awesome. As others pointed out, this would be perfect if it weren't for the fact that you have to use additional resources to use it properly. i.e. another dyno for Faye or use Pusher. Thanks for this though. Edit: One thing I would love to know is how this interacts with caching though. Russian Doll Caching specifically. Every time an attributed is update, does it bust the entire cache and have to reload that entire fragment - as opposed to just the partial?

chrismccord 14y ago
The partials each get separated into their own folder based on their model name. So it's not a grab-bag of random partials – it's the same folder structure an application would use for its regular views, but instead with a parent sync folder. ie, if a views/users/ directory contained "_profile.html.erb", you would move the sync partial to views/sync/users/. Having to run an additional process is the best case scenario right now unless we can get websockets into Rails/Ruby land, but I'm a believer that this approach is the best solution for current tooling suits the problem quite well. In regards to russian doll caching I'll have to take a look and verify what's going on under the hood, but sync will work fine with fragment caching outside and within a sync'd partial as long as the cache keys properly account for the resource/scope. When a model is updated on the server and `sync_update user` is called, Sync will render every partial to string in the views/sync/users directory, and dispatch a message to listeners on each channel for each partial. So the sync will only re-render what's contained in the sync'd partial. If you have fragment caches within your sync'd partial, they will only bust if their cache key has expired just like a normal render. Hopefully that helps. Thanks for the input/complements
- marcamillion 14y ago
  Ahhh ok. I get you, re: the caching. This is very cool. I have been waiting for something like this, to dive into the real-time web. Wading into client-side JS frameworks has been low on my bucket-list, but I am glad I can finally get something like this to add some 'rich interactivity' to my app. I definitely agree with everybody else, this should be baked into Rails core - for sure. I would have thought that with Basecamp Next and the direction that DHH said Rails was going (with aggressive caching and pushing only JSON down the wire) that this implementation would have been included in Rails 4. I was disappointed when it wasn't. Thanks for doing this. Really appreciate it.
- tomhallett 14y ago
  Can you provide some details on why the partials have to be namespace'd to the sync directory? My guess is: sync partials can only be "resource" based, and can't be given locals like a regular partial. Therefore, sync-partials are a subset of regular partials, so a different directory makes the distinction very clear. Just curious what the reason is. Looks very cool, I will definitely try it out!
  - chrismccord 14y ago
    You're right about part of the reason. One reason the partials are namespaced is indeed to serve as a distinction since at the moment, only the resource can hold the context for the partial. ivars will be visible from both the parent view render and controller sync calls, but likely not reliable since the partials will be rendered from different actions. The main reason they are namespaced is to allow rendering of all partials for the sync'd resource when publishing syncs in the controller. We can just ask the resource to give us all its partials in the views/sync/[resource pluralized] directory and only render those partials that are realtime, versus needlessly rendering all partials (including non-realtime) in the 'normal' resource directory.

chrismccord 14y ago

The partials each get separated into their own folder based on their model name. So it's not a grab-bag of random partials – it's the same folder structure an application would use for its regular views, but instead with a parent sync folder. ie, if a views/users/ directory contained "_profile.html.erb", you would move the sync partial to views/sync/users/. Having to run an additional process is the best case scenario right now unless we can get websockets into Rails/Ruby land, but I'm a believer that this approach is the best solution for current tooling suits the problem quite well. In regards to russian doll caching I'll have to take a look and verify what's going on under the hood, but sync will work fine with fragment caching outside and within a sync'd partial as long as the cache keys properly account for the resource/scope. When a model is updated on the server and `sync_update user` is called, Sync will render every partial to string in the views/sync/users directory, and dispatch a message to listeners on each channel for each partial. So the sync will only re-render what's contained in the sync'd partial. If you have fragment caches within your sync'd partial, they will only bust if their cache key has expired just like a normal render. Hopefully that helps. Thanks for the input/complements

marcamillion 14y ago
Ahhh ok. I get you, re: the caching. This is very cool. I have been waiting for something like this, to dive into the real-time web. Wading into client-side JS frameworks has been low on my bucket-list, but I am glad I can finally get something like this to add some 'rich interactivity' to my app. I definitely agree with everybody else, this should be baked into Rails core - for sure. I would have thought that with Basecamp Next and the direction that DHH said Rails was going (with aggressive caching and pushing only JSON down the wire) that this implementation would have been included in Rails 4. I was disappointed when it wasn't. Thanks for doing this. Really appreciate it.
tomhallett 14y ago
Can you provide some details on why the partials have to be namespace'd to the sync directory? My guess is: sync partials can only be "resource" based, and can't be given locals like a regular partial. Therefore, sync-partials are a subset of regular partials, so a different directory makes the distinction very clear. Just curious what the reason is. Looks very cool, I will definitely try it out!
- chrismccord 14y ago
  You're right about part of the reason. One reason the partials are namespaced is indeed to serve as a distinction since at the moment, only the resource can hold the context for the partial. ivars will be visible from both the parent view render and controller sync calls, but likely not reliable since the partials will be rendered from different actions. The main reason they are namespaced is to allow rendering of all partials for the sync'd resource when publishing syncs in the controller. We can just ask the resource to give us all its partials in the views/sync/[resource pluralized] directory and only render those partials that are realtime, versus needlessly rendering all partials (including non-realtime) in the 'normal' resource directory.