gabriel
Does Solid Router's APIs provide any way to abort a pending submission?
My issue is that I want to do optimistic updates, but if the user decides to change things way too fast, there will probably be some flickering, or the last value they had will not be the one on the database. I could also debounce the call to the action to avoid it being called multiple times, but even there this wouldn't be optimal.
I know that I can certainly have a
form and use the action there instead of calling and then abort the requests that are pending before the form submits by using the window.stop, but then the problem is that, because I have multiple small actions the user can do, a abortion meant for a certain action would end up aborting the other form action.
I'm not sure if Solid internally handles the actions using a fetch (I am using start so it might be more related to vinxi), but if it does, the best for me would to be able to pass in an AbortController to it. I also tried using the submission.clear function but that only clears the underlying data about the submission, it doesn't actually abort the request.
Has anyone thought about something like this? Would love to know if you were able to fix this or not. What kind of approaches you've taken.2 replies
How can I only set the ref for an element once it's been inserted into the DOM?
I've tried a few things but it doesn't seem like the element is inserted to the DOM at the point where the
ref is called, which does make a bit of sense, but I just can't find a proper escape hatch for this.
Tried:
- Using setTimeout(..., 0) before setting
- Checking if document.contains(...) before setting
- Using a hacky Mutation observer, not sure if I did my best on this one but doesn't seem optimal
For background, my use case is wit using https://github.com/lxsmnsyc/solid-floating-ui/tree/main (from @lxsmnsyc 🤖). The issue seems to happen when floating-ui itself tries to resolve the parent nodes for the floating element which do not exist at the point where the element hasn't yet been inserted in the DOM.47 replies
Setting properties to the unwrapped value of a store doesn't always propagate into the store
This is a bit of a mouthful but its actually a simple thing to see if you consider the following playground:
https://playground.solidjs.com/anonymous/671217f5-1742-45be-932f-494c85ee3a85
I also opened an issue on this because I feel a lot like this is a bug https://github.com/solidjs/solid/issues/2085.
I wonder if someone also had a similar use case or issue like this, would love to talk about it a bit here.
46 replies
How does the "You might not need an effect" page from react.dev translate to SolidJS's effects?
I feel like they are both the same construct, but since Solid has a fundamentally different way of rendering and constructing components it feels to me like a few things should differ. I was reading through it and thinking about this as I wanted to improve my own SolidJS code.
One of the things I am already sure it differs on is for the section of "Resetting all state when a prop changes": https://react.dev/learn/you-might-not-need-an-effect#resetting-all-state-when-a-prop-changes.
But as I mentioned, I'm not exactly sure how this section would look like on a SolidJS docs as we don't have one page for this, at least AFAIK. I first wanted to ask a question about this specific section of this react.dev page but I think it might be more interesting to actually discuss the whole page as there may be many things from this page that both might not apply as well might not be the optimal solution inside of SolidJS.
9 replies