I think of Spectator Sport as having two separate frontend systems:
The Recorder: some JavaScript that is served to all visitors/users of the parent application, running in the parent application’s own layouts and pages and alongside other JS and assets.
The Player: The Dashboard UI, and the JS/CSS that powers it, that’s mostly isolated from the parent application’s layouts and content
The Recorder
I expect this to appear in the parent application as a single JavaScript script served via a <script> tag
By default, the script file will be served via the application (route/controller/action/render(file:)) rather than the asset pipeline. I think the Rails asset pipeline is too fragmented in implementation right now to provide a simple set of instructions that would be compatible with 95% of Rails applications. That said, I expect the script to be static (e.g. not ERB) so that a developer could copy-paste and vendor it into their pipeline if they choose to (but I would consider that “advanced” set up).
I want all assets (JS / CSS) to not require any build-step, even for gem development. The reason for this is to make it simple to fork this gem, make a simple change, and still easily allow bundling via a Gemfile git: reference.
I believe it can be written in ES6. I think fetch support is a reasonable browser compatibility requirement, which means that ~ES2017 is reasonable to target, which does have JS classes and arrow functions. Service Workers are about on the edge. 95% browser share is probably sufficient, though if we get bug reports and there is a simple and more compatible replacement, I think we should do it for greater compatibility.
I think of Spectator Sport as having two separate frontend systems:
The Recorder
I expect this to appear in the parent application as a single JavaScript script served via a
<script>tagBy default, the script file will be served via the application (route/controller/action/
render(file:)) rather than the asset pipeline. I think the Rails asset pipeline is too fragmented in implementation right now to provide a simple set of instructions that would be compatible with 95% of Rails applications. That said, I expect the script to be static (e.g. not ERB) so that a developer could copy-paste and vendor it into their pipeline if they choose to (but I would consider that “advanced” set up).I want all assets (JS / CSS) to not require any build-step, even for gem development. The reason for this is to make it simple to fork this gem, make a simple change, and still easily allow bundling via a Gemfile
git:reference.I believe it can be written in ES6. I think
fetchsupport is a reasonable browser compatibility requirement, which means that ~ES2017is reasonable to target, which does have JS classes and arrow functions. Service Workers are about on the edge. 95% browser share is probably sufficient, though if we get bug reports and there is a simple and more compatible replacement, I think we should do it for greater compatibility.The Dashboard
I wrote up a little more over here about the Dashboard: https://github.com/bensheldon/spectator_sport/issues/3#issuecomment-2381026367
More simply, it can be done pretty simple with import maps (the browser feature, not the Rails gem) and no build.