QWu4xYV
enableScheduling causes simple solid router examples to crash
Wow, you already have a response.Yea! I was surprised too; very responsive!
Sounds like the kind of thing that Erlang (well, right now Gleam is the new hotness in BEAM-land)Right now it's just very prototype-y and scaling so far, but if it goes beyond that, Erlang/BEAM-land would be interesting to look into... Thanks for the pointers 🙂
7 replies
enableScheduling causes simple solid router examples to crash
Reporting it in the solid-js repoFiled here: https://github.com/solidjs/solid/issues/2176
Managed to address those yet?Mostly. Working on a simulation with low millions of entities as a toy/demo project, so any inefficiencies become glaring very quickly. It's my first project in Solid (coming from React), so a lot of the code I wrote at first was a bit at odds with Solid patterns. I feel like I'm getting a feel for things now though, thanks in part to community help 🙂
7 replies
enableScheduling causes simple solid router examples to crash
Oh, I did lose interest, which is part of why I forgot I had enabled it in the first place 😅
I'm not interested in fixing this bug so I can keep it enabled, I'm just reporting it in case anyone cares to fix it.
7 replies
Reactivity in single table cell from memoized data
@Maciek50322 @Dakotys , thanks so much for your detailed responses! While I knew a lot of it, the big thing that helped me unstick myself was the fact that Signals inside Signals (or Store inside Signals, etc) is okay. I stumbled across the fact that I could do this, but wasn't sure if it was a recommended pattern or something I should try to stay away from.
With this (and also the encouragement that
createComputed could also work), I created a few solutions here: https://stackblitz.com/edit/solidjs-templates-xaiwp8?file=src%2FApp.tsx
But all of those compute totals for the whole table, which at least in this case is less efficient. @peerreynders came up with a better solution on the original thread https://discord.com/channels/722131463138705510/1241054227485425734/1241901321171374140 , which takes this into account.
Thanks all!11 replies
Reactivity in single cell in nested For tags
@peerreynders , thanks so much for the detailed response and example! Your example solution brought up a couple questions:
1. What is the reason for changing
props.data to be an accessor instead of an array? I tested your solution without that change and it seemed to function the exact same, but maybe I'm missing something...
2. I noticed that the val() in <td>{val()}</td> will be an accessor (to be a primitive it would need to be val()()). After some more testing, I realized that Solid will automatically resolve Signals in JSX tags, even though TypeScript will complain about it. I didn't see that in the docs (maybe it's there an I missed it); is it something we should be able to rely on (and if so, I'd be curious why TypeScript complains about it), or should we be checking if val() is a function and handling that?27 replies
Reactivity in single cell in nested For tags
Moving to separate question here: https://discord.com/channels/722131463138705510/1241645514563391488/1241645514563391488
27 replies
Reactivity in single cell in nested For tags
Follow-up question (also happy to just make it a separate question if that would be better): What about if I need to do some transformation on the store data before displaying it, and still want minimal DOM updates?
For example, in https://stackblitz.com/edit/solidjs-templates-inkran?file=src%2FApp.tsx , I aggregate over each of the keys. With a
createMemo and some use of prev, I can get just a single row to update, but would ideally just update a single cell. (My understanding is that in this case, because createMemo returns a Signal (not a Store), there isn't a good way to listen for nested values, but I'm not sure about that...)
If I have my createMemo update prev in place, it seems that For/Index doesn't know that the update has happened (which makes sense), but if I create a new object for that row, even if a value hasn't changed for that index, it still updates anyway (in this case, the label "B").
What am I still missing here?27 replies
Reactivity in single cell in nested For tags
Thank you both, that was super helpful! Two main takeaways for me:
1. @peerreynders , I had previously had increment just updating what I needed to, but because I didn't realize about #3, I was confused about why it wasn't updating. Thanks for pointing that out!
2. @Dakotys , tbh, I just didn't realize that the <Index> component existed at all. I just looked through the API reference and saw the <For> component and used that. Thanks for pointing me in the right direction!
Not sure the general docs philosophy, but maybe a short sentence at the end of the API docs for <For> like this could be helpful: "<Index>(link here) is another component used for rendering lists, check out this section of the tutorial for more info on when to use each(link here)"
27 replies
Circular references in Stores?
Also, how long does it usually take for issues like this to get a root cause? Just wondering if I should rework my code that originally ran into this issue (which was more complex than dogs and trainers), or wait
29 replies
Circular references in Stores?
Posted here: https://github.com/solidjs/solid/issues/2056 . Feel free to add any additional context you think might be helpful!
29 replies
Understanding memoization re-running
As for why my code was structured in a convoluted way, the main intent was to use the outer simpleMemo to maintain consistent object references based on the input args, and the inner createMemo to memoize expensive computation done on the list (which in my use case can get very long).
There's almost certainly a better way to structure it; I just ran into this while throwing together a solution and it revealed that there's something I didn't understand about Solid, so I wanted to ask primarily for the sake of understanding.
13 replies
Understanding memoization re-running
Thank you both! Ownership is the main concept I was missing, and now that I understand it, it totally makes sense why my code wasn't working.
@bigmistqke , I know you posted in the #docs channel about this; just wanted to agree/add that I do think having a section on how ownership works in the Guides section would be helpful. Once I knew that's what I was missing, I was able to find the documentation under
getOwner/runWithOwner, but I expected that I could learn all the key concepts to understand the API docs from the Guides, rather than inferring concepts from the API docs. I do see some mention in the "SolidJS: Reactivity to Rendering" link, in the Reactivity section of the Guides, but an explicit section (or maybe subsection under a new "Advanced" heading) inside Reactivity would be great.
To be clear, I think overall the docs are great and I appreciate everyone who has worked on them (thank you!), just wanted to offer the feedback 🙂13 replies