Navigating through @solidjs/router doesn't load global app.css
When navigating from index to another route, the app.css doesn't persist as a <style> tag, despite being imported in the app.tsx file.
Demo project: https://github.com/zimonitrome/solid_error_demo.git
To reproduce:
npm install, npm run dev, click "page 2" -> "home" -> "page 2" from the navigation links.
Side question: Why are styles added twice? See second image. This seems like default Vinxi behavior.
18 Replies
@Katja (katywings) do you know anything about this? You helped me out here: https://discord.com/channels/722131463138705510/1260841964857720833/1260841964857720833
Which fixed my previous problem which was very similar.
There was a PR about this https://github.com/nksaraf/vinxi/pull/294. I guess it didn't fix all issues of this sort 🙈
GitHub
Build software better, together
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.
thank you so much 🙏 I was going a little crazy
gonna try to comment on that PR/issue
Youre welcome 😊, I hope we can solve the rest of these issues swiftly 😁
Nice. I posted this even more simplified version of the problem here in the original issue thread:
https://github.com/solidjs/solid-start/issues/1401#issuecomment-2233170499
Do you think this will be visible or should I create yet another issue?
maybe @ryansolid could reopen the issue
I talked to Nikhil about this a bit.. his reference counting approach doesn't work on the server which I believe is where the problem came in. It's related this issue right: https://github.com/nksaraf/vinxi/issues/318
GitHub
[BUGS] Styles in prod are injected twice and have wrong order · Iss...
The same styles are injected twice (into head and then into body). The styles are injected in incorrect order (in head they have correct order, and then in body incorrect):
I think the decided solution was handle it in SolidStart and probably rip out this logic as it can't handle SSR properly anyway.
I'm not entirely sure it's related but both are unexpected behavior.
As long as you and Nikhil are aware of the problem then I'm happy :)
It appears to only be a problem in dev anyway. It's just an inconvenience when debugging and implementing routing behaviors.
Oh that issue suggests there is an issue in prod..
to clarify: the duplicate CSS links are still a problem in prod, but the missing css links are not
so my application works fine in prod, albeit with some overhead of duplicate links
Ok can we talk about abou the missing ones then. I want to get what is going on. The reason we added the reference check stuff was styles were being added and then completely unloaded on navigation if the root and the page both imported. It would see that style for the page and remove it not realizing it was also being used by the root. Is this what you are seeing?
For the duplicated entries in prod I explained the reasons in this comment: https://github.com/nksaraf/vinxi/issues/318#issuecomment-2188951604 (Duplicated CSS entries).
The duplicated <style> entries in dev are a different issue I think, as @zimo mentioned :).
It would see that style for the page and remove it not realizing it was also being used by the root. Is this what you are seeing?No, not explicitly at least. I have an app.css which is only imported in app.tsx. App.tsx has a router to two pages: "index" ("localhost:3000/") & "page 2" ("localhost:3000/otherpage"). But the weird part is that it only happens when I import signals from other components (something I do very liberally). I tried to demonstrate it with this diagram from a minimal example:
The yellow boxes in the image are signals.
When either of the two signals are NOT imported, the css is loaded as expected. I.e. if "ref1 or "ref2" in the image is broken, the problem disappears.
So maybe what happens is that index.tsx loads compB.tsx which loads app.tsx and all along the way the app.css is seen by Vinxi as being imported by index.tsx. Hence why it gets removed when navigating to otherpage.tsx.
Again, here is my comment on the GH issue:
https://github.com/solidjs/solid-start/issues/1401#issuecomment-2233170499
I tried making an as minimal as possible project to demonstrate the problem:
https://github.com/zimonitrome/solid_error_demo
Yeah ok.. I see.. you are actually importing app.tsx from CompB
which means that yes it would also get app.css
I strongly recommend not exporting more than one thing from app or from page components.. Just pull into a shared location they both can grab from. In general I guess app being top level means it is everywhere anyway but we have no choice to assume that the CSS is needed again from there.. My guess is because this is over page boundaries Nikhil's approach to deduping didn't work.. Ours should
Okay thanks. I have generally defined a bunch of signals in their corresponding components, then exported them and checked them in other components.
Example: NavBar.tsx defines and exports [navBarOpen, setNavBarOpen] so that I can close the navbar when another component prompts an alert for example. (akin to "compBProp" in my diagram)
Another example is a global signal [isMobile, setIsMobile] which determines page layouts. (akin to "appProp" in my diagram)
What would be a better way to define these signals?
Use a global store in its own .ts file? Define all signals in a common .ts file?
Are there any guidelines on patterns like this?
There are a few things here. Context is most often used. But yeah usually extracting stuff out. At a certain point everything would just become a megabundle we couldn't break apart very easily (we can remove unused exports, but we can split a single file apart different chunks with modern bundlers). Often forr this sort of high level state there are a few common things that you will ask all over the place or need to set a few locations but for the most part this can be hoisted up and then used to orchestrate throughout the app.
I see. I use context very rarely and should looking into understanding it better and using it more often probably :)
Thanks