Experience exchange

[antulik]

Hi team. First of all I want to say good job!

I wrote multiple component libraries myself, including https://github.com/antulik/pagelet_rails and recently almost identical implementation of motion gem. I experimented with every possible implementation, including ajax, polling, websockets and server state. After all of that I'm excited to see motion project.

As I mentioned I implemented a very similar library to motion which I'm using in production. I don't think I have capacity to opensource and maintain my own implementation, so I'm keen to share my experience and contribute to motion instead.

I had a quick motion overview and few things stand out.

1. Separating use cases

What do you think about separating different use cases? I can see at least two main:

a. live components - components that auto update on events
b. live components with interactions

Live components without interaction have less limitations (like single DOM element) and potentially the implementation could be more lite-weight. It seems motion is pushing hard on interactions, but I think live updates is much more powerful feature which is much easier to adopt and migrate from classic Rails or view components.

2. State serialization

Currently the component state is serialized with all instance variables. Have you considered json serialization or explicit serialization?

While Marshaling is magically convenient, there are many issues with that approach, like security, edge cases, and dump size.

Some ideas:

• I'm thinking something similar to rails session with identical behavior. The concept is already known to rails devs. The name could be state or component_session.
• Alternatively the state could be serialized explicitly, e.g. to_json/from_json, or to_state/from_state
• Or just like map_motion lists actions, map_data could map session data.

We would need to serialize the initializer arguments as well, I personally serialize it with ActiveJob::Arguments.serialize so the behavior is consistent with ActiveJob.

3. AnyCable support

I can see AnyCable is on roadmap. Have you looked at AnyCable yet? If I understand motion correctly, it saves the state as part of actioncable connection. If that's the case, such approach is not compatible with AnyCable https://docs.anycable.io/rails/compatibility .

Personally I opted for slightly different architecture. Browsers subscribe to event streams without sending component state. When browsers receive new events, they request a refresh from the server and include the component state. Such architecture adds one request round-trip, but gives more flexibility. That puts less demands on the server and implementation could be vary. For example I was able to swap websockets with long polling (https://github.com/discourse/message_bus) and use ajax for component updates instead of websockets.