DEV: Don't use `js.erb` for constants (PR #9711)

Adds a new rake task to auto generate a constants.js file with the constants present. This makes migrating to Ember CLI easier, but also slightly speeds up asset compilation by having to do less work.

If the constants change you need to run: rake javascripts:update_constants

GitHub

Hmm, having both a file template (in lib/tasks/javascript.rake) and its output (constants.js, with “don’t edit” note) in a repo isn’t ideal. :thinking:

If the endgame is to make the frontend app more or less standalone (e.g. to make it possible to run with any backend, local or remote, or with a simulated backend via Mirage) then maybe we should have those constants available as an endpoint (and seeded in data-preloaded)?

@CvX these constants almost never change though. I considered making an API endpoint and preload but why even bother querying and building JSON all the time if it never changes? It’s a lot of pointless work.

As for the template having that comment, I feel like people will understand that’s where things are generated from the name of the task and comment. Are you worried that people won’t know how to edit the template properly?

Those two constants may rarely change, but might add more. And are these the only consts that are shared between frontend and backend? Of the top of my head I can think of pretty-text, where the direction of sharing is reversed (it’s the backend that pulls the JS files). Surely there have to be more, how are those shared?

Are you worried that people won’t know how to edit the template properly?

I’m sure everybody will figure it out, I’m just not sure about adding to the repo what’s essentially a build artifact. :smiley:

@CvX I’m currently going through the app and removing all .erb usage. This solution works for constants that rarely change (and I plan on extending it to Emoji.) For things that change frequently they are already in the PreloadStore.

I do understand not wanting to check in the build artifact, but the alternative is doing a bunch more work on every request for a user. This seems like the lesser of two evils and I can’t think of a better way to do it that achieves the same performance.

A minor thing: aren’t we using the THIS_CASE for constants?

Oops, I’m not sure how but I merged this into master already by accident! Oops!

I did a follow up commit for the UPPER_CASE constants, thanks!