Skip to content

Warm cache and handle frozen import maps - #329

Open
etiennebarrie wants to merge 2 commits into
rails:mainfrom
etiennebarrie:render-frozen-import-maps
Open

Warm cache and handle frozen import maps#329
etiennebarrie wants to merge 2 commits into
rails:mainfrom
etiennebarrie:render-frozen-import-maps

Conversation

@etiennebarrie

Copy link
Copy Markdown

This PR helps for Ractor support. The Rails application can then deep-freeze (Ractor.make_shareable) the application map at Rails.application.importmap, and it becomes usable from worker Ractors rendering views with the importmap helpers (at the cost of not caching the results anymore).

In addition to not raising an exception when the map is frozen, this also pre-warms the cache during boot for eager-loaded apps. This is helpful for any deployment using preforking.

Since we don't know exactly the list of all entry points, and to avoid adding a new configuration option, we use "application" and all the entry points mentioned as preload targets for the pins. That is if you use a string or array of strings in the preload option, they are all considered entry points.

For example in the README example:

# config/importmap.rb
pin "@github/hotkey", to: "@github--hotkey.js", preload: 'application'
pin "md5", preload: ['application', 'alternate']

# app/views/layouts/application.html.erb
<%= javascript_importmap_tags 'alternate' %>

# will include the following link before the importmap is setup:
<link rel="modulepreload" href="/assets/javascript/md5.js">
...

This will pre-warm the cache for "application" and "alternate" automatically.

Let me know if you think we should add a configuration option in addition to that, which would allow pre-warming the cache for an entry point that is not explicitly listed but only used in a view/layout.

A frozen map currently raises when caching resolved paths or the
generated JSON. Instead, skip the cache when it is frozen.

This allows sharing the import map between Ractors, which requires
deep-freezing it, cache included.
Instead of waiting for the first request, warm the cache as best effort
during boot for eager-loaded applications.

Rather than adding a configuration option, this uses the entry points
provided in the preload options of the pins. If an entry point is not
listed in any of the preload options, it won't be pre-cached, except the
for the default "application" entry point.
@etiennebarrie

Copy link
Copy Markdown
Author

I have the same failures on main. Something with the CDN I guess…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant