javascript_pack_tag handles repetition of individual chunks. Closes #39 #91
Conversation
vtamara
changed the title
|
Rubocop tests passed locally (I wonder why not in the CI). |
|
@vtamara Thanks for the PR, from a quick glance, I think it might hit similar problem that I had when trying to make this work with repeated declarations. Essentially what we're lacking is the context from where javascript_pack_tag has been called. Let's say that you have one declaration in the main layout loaded in the head, other loaded somewhere in the partial for specific part of the page only. Once the page gets processed, the partial one would be processed first and emit script tags wherever it was declared and we would end up with no repetition in the head. Some scripts will however complain about not being declared in the head tag. This might cause some fubars with Turbo also but that's just a suspicion 🤔 |
Thank you. I guess it is good idea to enhance the example with:
And to see what it does and how to deal. |
…ent once those of application and layout and after the queue
| end | ||
|
|
||
| # Determine if we are in a partial template or in the main one | ||
| partial = caller.filter{|c| c.include?('partial_renderer')}.count > 0 |
There was a problem hiding this comment.
@vtamara i think we're getting closer but don't quite like this bit. I'll try and figure out if there are some better ways to do it.
Alternatively, it's more overhead and bit more difficult for users to use but if we split the implementation here into a helper that populates a queue and then javascript_pack_tag is still only callable once (and uses the queue), I think we will have an implementation that solves the main problems we're facing with this.
There was a problem hiding this comment.
This has issues on several levels:
- What if the method name filtered for changes?
- Performance?
- Completely unconventional to have production code using the call stack to figure something out.
| # | ||
| # <%= javascript_pack_tag 'calendar' %> | ||
| # <%= javascript_pack_tag 'map' %> | ||
| # There should be at least one javascript_pack_tag in the main template |
There was a problem hiding this comment.
main template, main one ==> main view
partials, can be used on any views, including:
- Other partials
- Main view for the controller action
- Layout for the controller action
Order:
- Main View => includes partials, content_for blocks
- Layout => will use the main view and any content_for blocks, and any partials directly on the layout
|
|
||
| options[:defer] = defer | ||
| if !defined?(@emitted) | ||
| @emitted = {} |
|
Closing this. Too fragile. I gave @vtamara some ideas on how we can remove duplicates from the final result HTML string after rendering the whole layout and before the server sends the result to the browser. |
This one would close #39.
The idea is to record what chunks have been emitted and with what defer value.
When a chunk previously emitted is going to be emitted again, skip repeating it so long as the defer value is the same as the previous one, or raises an error if different.
But what about the order of chunks?
This way, the components in the loaded packs could be used anywhere, and it would be possible to repeat
javascript_pack_tag without actually loading the chunks repeated.
I guess there are situations I'm not considering.
I also think that before merging this, it is essential to fix #88 (we don't want to confuse what is causing that bug with this!)