[question] broadcast to multiple clients about motion HOT 3 OPEN

In my opinion, the most logic thing to do is to broadcast rendered html (option 2), but be able to somehow ignore the rendered slide while serializing. Either by customizing the way serializing works per component or by adding one specific ivar like @ignored_state that behaves like a hash (and may need an api to set and get items like ignored_state(:slide_html).

Not only would it be important to ignore serializing those ivar(s), wouldn't these ivar(s) need resetting after render so garbage collection can free up some memory? It would be up to devs to create a backup system in case the state isn't available (using memoization).

On another note: could you elaborate on your intended goals with motion? It's really helpful to us and we see a future with a lot of use of it. That said, we're somewhat hesitant as the project could use extra marketing, documentation and support. We absolutely respect the fact that you don't owe us anything at all. It's just that, we would really like to bet on this tech and would want to know what your goals are.

from motion.

The way to solve this problem with Motion right now is your option 3. It's possible that it's not the right choice at the moment based on the fact that you think this would overwhelm server resources. But I won't rule out possibly supporting options 1 and 2.

The intended goals for motion are for it to support building rich frontend components with minimal or no js required. There are lots of different use cases there and I think currently we're open to supporting more.

I'm 100% with on the expanded marketing and documentation and it's something we know we need to work on.

from motion.

did I miss a solution that may perform better?

With the way Motion's public API works now, I think those are your options. If you're willing to risk breaking in the future, you could provide your own implementations for marshal_dump and marshal_load. Personally, I prefer the first option (cache the slide on the server and put the cache key in the state). This is the closest to "server side state" which is something that I would like to see added to Motion in the future.

In my opinion, the most logic thing to do is to broadcast rendered html (option 2), but be able to somehow ignore the rendered slide while serializing.

This has come up a few times now. I'm hopeful that we will be able to find a way to do things like this that does not involve allowing/denying state at the ivar level, but I'm not opposed to an API that would add support for this. Internally we already maintain a list of problematic ivars that come from the view state.

could you elaborate on your intended goals with motion?

Motion is a passion project for me. I'm still very interested in it and have no shortage of things that I would like to do, but my primary focus right now is settling into a new professional position.

Here are the things that I think need to be done and would like to do when I have the bandwidth/inspiration:

• Server-side state
  Currently, Motion stores state in the DOM on the client. Instead, I'd like to have it store data ✨ elsewhere ✨ and send only a key to the client. The location should be configurable and default to wherever ActionCable is configured to store its state (probably Redis in most apps).
• Something analogous to React's key
  Currently, Motion does not individually identify components in the client and this causes a lot of connect/disconnect churn on lists. It also makes some other optimizations I would like to make very difficult. It should be possible to uniquely identify components if the programmer provides a key for items in lists.
• Arenas (and broadcast-less callbacks)
  Currently, components in Motion are completely isolated once connected. They each have their own subscription in ActionCable and communicate solely through broadcasts. Instead, I think components should be mounted in an area that holds the channel. This would allow components to hold refs to each other and remove the need to use broadcasts for callbacks.
• Stopping unnecessary re-renders of nested components (probably with a proper Motion::Component.replace_with(old_component, new_component) lifecycle method)
  This depends on arenas and keys. Motion does preserve the state of nested components, but currently the responsibility of reconciling is left solely to the client. This means that the server always renders the new versions of nested components when an outer component re-renders; the client just discards it when "the outer state" has not changed. Instead, the client should reach out when it needs to replace a component.
• Something analogous to Phoenix LiveView 's phx-update
  Currently, the longer a list gets in Motion, the more work the server has to do to render the component. There is no way to only render the "new" items. There is also no way to ignore sections of the DOM tree completely (perhaps for integration with other JS libraries).
• Range-based reconciliation
  Currently, Motion requires all components to have a single root element. Also, only elements that can exist at the root of a DocumentFragment are allowed (this notably excludes elements like tr and td). Instead, component boundaries and tracking information should be stored in comment nodes which can appear anywhere in a document.
• Client-side timers
  Currently, timers are managed by the server, but this requires an ugly extension to ActionCable and (more importantly) is not compatible with AnyCable. Instead, the client should manage the timers and wakeup the server as necessary. This is slightly less efficient and changes the security model a bit, but I think it is worth the reduction in complexity and additional compatibility.
• Signed broadcasts and client broadcast relays
  This doesn't make sense to do until callbacks no longer use broadcasts. Currently, when a component subscribes to a broadcast (via stream_from or stream_for), this subscription is made on the server. This is supported by another ugly extension to ActionCable and (more importantly) is not compatible with AnyCable. Instead, the server should provide signed tokens that the client can use to subscribe to broadcasts and relay those messages back to the server. Again, this is slightly less efficient and changes the security model significantly (the stream_from interface should probably be deprecated and eventually removed completely in favor of stream_for which can be encrypted), but I think it is worth the reduction in complexity and additional compatibility.

from motion.