Create route which opens a modal
In SolidStart and using Solid Router, I'm trying to create a route for a modal. Specifically, I want to have a log in link that opens a modal when it is clicked, with whatever page the user was on to remain in the background. I also want the URL to be updated to reflect that the modal is open, which is where the difficulty comes in.
How could I accomplish this?
10 Replies
I think
<Show> component is a proper method to meet your demand. Based on the prop of When and the signal of showModal to control the Modal whether open or not.Just a rough outline of where I might start (i.e. so no guaranties).
- useSearchParams gives you access the URL parameters creating the opportunity to indicate your modal state there.
- Inside the root component include your modal so that it is available on every page.
useSearchParams should be able to work there. Use a derived value off of the params accessor to drive in the JSX whether or not the modal section is part of the document flow.
- The "login link" (also part of the root component) can acquire the current URL parameters via the useSearchParams accessor (which you can untrack) and then control the modal's state via the useSearchParams setter (which also accepts a NavigateOptions parameter (described here)).MDN Web Docs
What is a URL? - Learn web development | MDN
A URL (Uniform Resource Locator) is the address of a unique resource on the internet. It is one of the key mechanisms used by browsers to retrieve published resources, such as HTML pages, CSS documents, images, and so on.
GitHub
solid-start/examples/basic/src/app.tsx at 771aedebb55bf43471d0ae471...
SolidStart, the Solid app framework. Contribute to solidjs/solid-start development by creating an account on GitHub.
Thanks for your response. My concern is really with controlling the modal via the URL, no merely showing it.
Thanks for your reply. This seems like a good place to start when it comes to using the URL to control the modal.
What are your thoughts on using a URL without query params? So the URL would change to "example.com/login", and the modal would open up over the currently viewed page. How would you go about this?
I realize this is a more complex scenario when it comes to routing, but this is what I was envisioning, and outside of the login modal I would like to know how to implement this for other cases.
My initial thoughts are to use
useBeforeLeave to read the URL before leaving the current route. If it is for the login URL, then the navigation is cancelled and the modal is opened. Then the new path is manually added using the History API.
Your thoughts?Anything is doable given the requisite effort.
However from what little I understand about solid-router and SolidStart that doesn't seem to be an approach that fits seamlessly into the compositional model they have chosen (... I could be wrong).
example.com/login could be addressed with an optional parameter while the modal itself could be shared somewhere higher up in a parent layout for a nested route.
But I think going with the search parameter approach you are getting more "locality of behaviour", while example.com/login is more of a stylistic choice that may require some stubbornness on your part to continuously smooth over the rough edges that it introduces (I'm more than familiar with the "but I want it to work this way" mindset).
If useBeforeLeave and the History API is something you want to wrestle with, give it a go.MDN Web Docs
History API - Web APIs | MDN
The History API provides access to the browser's session history (not to be confused with WebExtensions history) through the history global object. It exposes useful methods and properties that let you navigate back and forth through the user's history, and manipulate the contents of the history stack.
SolidStart Release Candidate Documentation
SolidStart Release Candidate Documentation
Early release documentation and resources for SolidStart Release Candidate
My 2c is that a route is a route. If I'm reading your request right, you want to shoehorn functionality that should be a simple boolean value in a global context into the router logic.
i.e. example.com/login should go to a login page, having that in the url bar when on example.com/pricing would navigate to example.com/login, not keep the user on the pricing page with a login popup.
I have this exact functionality with a contact form and no messing around with routes. Store a 'loginFormOpen' boolean in a globally available context, and have the login form hidden via
<Show> somewhere pretty high up the tree. Now, from anywhere in your site, you can flick that boolean to 'true' and your login screen can magicaly overlay any content that is currently on screen. Add Solid Transition Group for some sparkle.Yes, it's certainly a case of "but I want it to work this way". I like the flow, but it does come with complications. I will try it, but I may very well end up doing it the simpler way.
Thanks for your reply. I agree with you in that it's trying to "shoehorn" functionality that the router doesn't intrinsically support. But it's the lack of compatibility with the router, and not the pattern itself which is the issue, imo. I'm going to test it out and see how much of a headache it gives me.
cool. So just so I'm clear on what you're wanting: if someone goes to mydomain.com/login, it shows a regular login page, but if someone goes to mydomain.com/whatever, and clicks a login button, you want the browser to display mydomain.com/login, but -not- navigate to the actual login page, but instead display the login overlay?
Yes, you described it perfectly
yeeeeah, that's gonna be a pain in the ass afaik. Just use a context, or throw a
?loginopen=true as a param on the end of the url that you can read globally and be done with it 🙂
but if you do get it working well, post it here, I'd be keen to see it in action!Yes, if I get it to work well, I'll post it here.
I'm putting this idea aside for now, after several hours of trying 🥲
Solid Router cannot track when you manually set
window.location (as expected), or when you use the History API to navigate. And there is no API to keep it in sync (from what I can see in the docs).
I've seen a few other complaints about the router not behaving as desired when back and forward buttons are used, and I'm experiencing the same thing.
I think a good exercise would be for me to dig some more into the router code and see how it works. Maybe I will have some ideas about how to improve it.
But for now, I'm using the more straightforward query params way to get this done.