ApplicationController context

[scottbarrow]

Bug Report

Describe the bug

I am trying to futurize a view that relies on helpers that are included only in the subclass of ApplicationController, futurism render's in the context of ApplicationController.
https://github.com/julianrubisch/futurism/blob/abb5bcf31c9cb381777b623c5f4768ddc8eda67d/lib/futurism/channel.rb#L28

Would you be open to having an override for the controller constant, potentially set on the connectionobject? or is there a better way to handle this?

secondly, controller params are not available in the channel,
meaning that in my case the helper used in the partial being rendered by futurize that depends on params to get current_* will not work, are you able to suggest a way of rendering in the context of a custom controller with params?

To Reproduce

Render a partial with futurize that uses a helper in a subclass of ApplicationController.
also, in the helper add a method that reads request params

Expected behavior

Expect to be able to specify controller class
Expect to have access to params

Versions

Futurism

• Gem: [e.g. 0.5.0]
• Node package: [e.g. 0.5.0]

External tools

• Ruby: [e.g. 2.7]
• Rails: [e.g. 6.0.0]

[rickychilcott]

@scottbarrow my approach in #62 was to make the controller able to be overridden per futurize statement because it doesn't seem like you'd want every connection to always use one single controller.

[scottbarrow]

@rickychilcott I like the idea of passing it per instance of futurize, however this may become tedious in my case where the majority of my controllers inherit from a sub class of ApplicationController. Could you maybe consider an initializer in addition?

[rickychilcott]

Also, I didn't address params passing in #62

https://github.com/hopsoft/stimulus_reflex/blob/9d3149cbe37f579420285938db13880214392001/lib/stimulus_reflex/reflex.rb#L64-L88 may give us a hint about how best to approach pulling in params. I believe client-side, we'll want some JS to package up the current URL with each message down the wire, which can then be parsed server-side, and params passed to the controller as it's executed. That way, as you move from page to page (and assuming the WebSocket isn't broken), the params will change based on the current page's URL. I believe this should be a separate PR.

[julianrubisch]

I believe this should be a separate PR.

+1

I'm testing #62 right now, will likely merge it tomorrow (CET)