Updating Template before CSS causes template to not pick up scoped class name about ember-scoped-css HOT 4 OPEN

Something else to note, if you redo the first few steps without adding another div, but adding a second class to the second div, the scoped class is applied. But then if you remove the duplicate class name, the element returns back to the previous state with no scoped class. I'm assuming it's likely a cached key issue (with the single "bar" class):

1. Create a template file containing a div with a single style

// hbs
<div class="foo">foo</div>

2. Create an accompanying css file with the style for the div

// css
.foo {
 	color: red;
 }

3. Observe the rendered HTML does not have a scoped class name for foo

// html output
<div class="foo">foo</div>

4. Update the template file with a second div with a second single style

// hbs
<div class="foo">foo</div>
<div class="bar">bar</div>

5. Observe the rendered HTML after build has applied the scoped class name for foo

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar</div>

6. Update the CSS file with a style definition for bar

// css
.foo {
 	color: red;
 }
 .bar {
 	color: green;
 }

7. Observe the rendered HTML after build to see there has been no change to the scoped class definitions.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar</div>

8. Add a second "bar" class to the second div and save the template file

// hbs
<div class="foo">foo</div>
<div class="bar bar">bar</div>

9. Observe the rendered HTML after build to see the scoped class definitions applied.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar_ee3b6cad0 bar_ee3b6cad0">bar</div>

10. Remove the second "bar" class from the second div and save the template file

// hbs
<div class="foo">foo</div>
<div class="bar">bar</div>

11. Observe the rendered HTML after build to see the bar scoped class definition has reverted.

// html output
<div class="foo_ee3b6cad0">foo</div>
<div class="bar">bar</div>

Definitely appears to be cache key related, if you revert an element to the state it was before a class was defined, it undoes the scoped class, essentially reverting to the previous state when the class didn’t exist.

from ember-scoped-css.

After running into the issue again, I decided to do some digging and discovered that part of the issue is that the babel plugin only runs on hbs changes. There may be some order of operations happening with making the hbs change first before the class exists. Adding the class to the css doesn't run the babel plugin, and finally trying to resave the hbs file doesn't re-trigger the babel plugin. I am assuming that is due to some caching, which I have verified is happening by returning the file to a state that had previously been processed. Making a new change (that has never been saved and processed) and saving the hbs file will eventually retrigger the scoped-babel-plugin.

So ultimately, the issue appears to be:

1. Changes to css files do not trigger the scoped-babel-plugin
2. Changes to hbs files that have already been processed by the babel plugin do not run again, which can cause a state where a css class will never be picked up unless the hbs file has a change that has not been processed by babel.

I'm not sure exactly what the answer is, but that appears to be the source of the issue.

from ember-scoped-css.

Pinning and re-opening because the implemented solutions has caused some confusion, and the problem goes away if we adopt a solution similer to https://github.com/cardstack/glimmer-scoped-css (have everything in one file)

from ember-scoped-css.

A way to solve this (that we talked about at the onsite), was being explored here, but we can't currently pursue that implementation because it would mean we lose HOT loading of CSS, which is a requirement for us internally due to how numerous our dozens of app MB are.

We may have to

• give up on hot loading of CSS (to potentially solve this problem)
  (this is because the CSS hot loading technique we use now is dependent on the legacy style pipeline, and we wouldn't be using that with "the fix" -- we'd make all CSS part of the module graph)
  ((I could be wrong here, and this may still need more exploration (and it's still worth doing that exploration, as we'll want a more robust solution when we get to vite anyway, something that plays nicer with "compile only what you see" --- but for now, I'm deprioritizing this exploration)))
• or migrate to embroider/vite all at once (maybe via flag so folks can beta test)

Right now, our scoped-css approach is at risk because we don't have parity between embroider and non-embroider. See here for details #120
We can re-gain that parity, but it'll just take some time.

from ember-scoped-css.