When css-module is turned on, the .goto-active css is hashed.
Source css
.goto-active {
background-color: lightgray; }
Processed css by css-module
._2hWcg4XS-nSqj0MHIpiu3O {
background-color: lightgray; }
Expect router sends through all the injected css class names (if there are more than just .goto-active) to go through proper css-module handling done by @EisenbergEffect .
The current behavior is that the injected .goto-active has no idea about css-module, resulting missing applied-style at runtime.
<a goto="welcome" class="au goto-active" href="welcome">Welcome</a>
It should be
<a goto="welcome" class="au _2hWcg4XS-nSqj0MHIpiu3O" href="welcome">Welcome</a>
Depends on the architecture, this could be a simple fix.
Irrevalent
| Software | Version(s) |
| ---------------- | ---------- |
| Aurelia |
| Language |
| Browser |
| Bundler |
| Operating System |
| NPM/Node/Yarn |
I don't know what goto-active is. Is the router adding that? If so, there needs to be a way to configure the router with a particular class so that the end user can import their css modules and set that with the runtime class name.
It's class injected by goto="a-route" attribute, based on current active route.
au1's way of explicit binding on class should work with css-module with no problem. But au2 tries to reduce user's work (which I like).
@EisenbergEffect there is a router config to set goto-active class to what ever class user wants.
Your suggestion should work, but it exposed the detail of css-module which we want to hide from end user. Let's see if that's the only option we got.
Isn't goto-active to be considered an app global class? Define it as a global style?
A real app will most likely have quite a few global scope styles defined anyway.
@mobilemancer you are absolutely correct.
For record, the skeleton now sets .goto-active as global css class when using css-module.
:global(.goto-active) {
/* ... */
}
Nice!
Most helpful comment
For record, the skeleton now sets
.goto-activeas global css class when using css-module.