It looks like we have a new race condition that may only be a problem in
specs. If you trigger one report, it displays via websockets and then
you trigger the next report, there may still be some Javascript active
that displays the first report while the second one is loading. I'm not
sure if users would navigate that fast though.
To minimise the problem, I adjusted the polling to leave more room for
the default websockets response.
This also resolves a race condition scenario. Even if the report gets
rendered via websockets before the controller response is rendered then
the fallback script loads the report again. It's not the most beautiful
but probably okay until we replace websockts altogether.
I'm leaving websockets in at the moment because it can render the report
much quicker than polling can.
The helpers are more convenient but also allow us to add options like
smooth scrolling. I thought that looked nicer and is less confusing.
Please note that the `scroll_into_view` helper uses the `targets`
attribute instead of `target`. That attribute needs CSS selectors with a
leading `#` for ids.
I'm adding TurboPower for the scroll_into_view action. It adds all the
nice CableReady actions to Turbo Streams.
Note that I omitted `block: "start"` because that option is the default
in Javascript. And the generic `action` method doesn't support
parameters like this anyway. I'll work on that in the next commit.
I also re-introduced a race condition by rendering the "loading"
indicator after triggering the report rendering job. I'm planning to
resolve that later.
Sending large reports via Cable Ready is unreliable. The events are
dropped at an unknown point and the report is never displayed to the
user. Instead we just send a link to the report via Cable Ready and
offer a button to load the report on screen.
This has the UX benefit of warning the user about the size as well.
Weaker devices can struggle rendering big HTML documents.
This is not a normal pattern for setting up ActionCable channels, so it might need some notes. It ensures the broadcasts from the ReportJob are unique not just to the user session but also to the specific tab in the user's browser. Otherwise if the user has two different report pages open in separate tabs with the same session, the broadcast would overwrite the #report-table element in both of them.
You can reach a development server under localhost, 127.0.0.1, 0.0.0.0
or other names you define in your environment. The reports were using
absolute links to localhost though and therefore breaking your session
(login) while navigating.
I'm not sure why this was done though. Sebastian didn't explain this in
the commit message and it may have been accidental.
