Setup a proxy object that wraps CableReady::Channels

[hopsoft]

Enhancement

Description

Expose cable_ready to reflexes through a proxy object to improve the developer ergonomics when emitting CableReady broadcasts from within a reflex on the StimulusReflex channel.

Example Usage

class ExampleReflex < ApplicationReflex
  def do_stuff
    # business logic....

    cable_ready
      .push_state(url: "https://example.com/123")
      .dispatch_event(name: "wtf", detail: {message: "Holy shit!"})
      .broadcast

    # default behavior of full page morph still runs
    # you could also opt to call: morph [SELECTOR, :nothing]
  end
end

Note this is the server side counter part to #381

Checklist

• My code follows the style guidelines of this project
• Checks (StandardRB & Prettier-Standard) are passing
• This is not a documentation update

[marcoroth]

Nice, this really improves the developer experience!

[hopsoft]

We should be careful not to encourage element mutations via CableReady if/when someone is using default reflex behavior.

[leastbad]

I will be addressing this in the docs, 100%.

One thing that might not be self-evident from the readme above is that this also implicitly solves the "how do I send a CableReady broadcast just to the current user" question, at least within a Reflex.

[hopsoft]

This blurs the line a little if someone is using morphs. For example, what is our recommendation on when to use morphs vs cable_ready directly?

[julianrubisch]

Can we use this also to decouple the broadcasters?

Comes to mind because I mocked CableReady::Channels pretty often in the tests

[leastbad]

Someone wise suggested that the easy way to decide if you need a StimulusReflex#morph vs a CableReady operation is whether you need StimulusReflex callbacks on the client afterwards.

[hopsoft]

@julianrubisch Yes, I expect this to open up some refactoring opportunities in the broadcasters, tests, and possibly elsewhere.

[julianrubisch]

So I‘m playing bad cop (again) - could you add some exemplary tests for StimulusReflex::CableReadyChannels ? This will further (my) understanding and facilitate future refactorings...

[hopsoft]

Yes and thank you for pushing hard on the tests @julianrubisch.

[RolandStuder]

Nice stuff!

We should be careful not to encourage element mutations via CableReady if/when someone is using default reflex behavior.

Could the proxy object not actually somehow prevent that by declaring a morph :nothing? <- stupid idea, of course you would want to be able to have selector morphs and such cool new cable_ready calls in on reflex

[leastbad]

Another excellent reason to require broadcast is that - at least right now - if they piggyback CR operations that aren't SR-specific on a broadcast that has SR operations, well, very bad things. As currently implemented, it would actually break because the code assumes every dispatchEvent/morph/innerHtml has a stimulusReflex accessor. All other operations would be silently discarded. Obviously not desireable.

I am going to have to make another pass on received that is more robust. I need to separate the data.operations into two objects: one that has stimulusReflex accessors and one that doesn't.