JCM Comments - Answer Overflow

Topics

JCM

•Created by ojack on 4/18/2024 in #support

Dynamically remove effect

Note that for simple logic like that, it's obviously more readable that way, but example above is to illustrate nested effects

createEffect(() => {
    if (enableEffet()) {
        console.log("this is only executed if `enableEffect()` is true", someOtherSignal());
    }
})

createEffect(() => {
    if (enableEffet()) {
        console.log("this is only executed if `enableEffect()` is true", someOtherSignal());
    }
})

5 replies

•Created by ojack on 4/18/2024 in #support

Dynamically remove effect

There is probably something triggering if the effect needs to be there or not. Note that in solidjs, the dependency tree from signal is fully dynamic, so assuming you have a signal enableEffect , you can do following

createEffect(() => {
    if (enableEffect()) {
        createEffect(() => {
            console.log("this effect only exists if `enableEffect()` is true", someOtherSignal());
        })
    }
    // when `enableEffect()` is false, the inner effect is not created
})

createEffect(() => {
    if (enableEffect()) {
        createEffect(() => {
            console.log("this effect only exists if `enableEffect()` is true", someOtherSignal());
        })
    }
    // when `enableEffect()` is false, the inner effect is not created
})

5 replies

•Created by gsoutz on 3/27/2024 in #support

How can I protect nothing ever breaks, while the setTimeout is waiting

Hard to guarantee that nothing ever breaks... A guess about a possible problem in your code snippet is that the effect can be re-executed before the timer expires, which will then call on_next_puzzle() twice. Usually you want to clean the timer in a onCleanup(() => clearTimeout(timerId))

2 replies

•Created by gsoutz on 3/15/2024 in #support

How to avoid passing props all over the place

To go back to the second question, I think you can pass a class storing a few signals and maybe some memos as a single prop. I don't see why it wouldn't work. The more idiomatic coding style for solid-js is to split everything in separate props, and pass values, not signals in props (eg. not <MyComponent myProp={mySignal}/>, but <MyComponent myProp={mySignal()}/>). In the component it's used as a value (but behind the scene, the prop is a getter, so it calls the signal).

18 replies

•Created by gsoutz on 3/15/2024 in #support

How to avoid passing props all over the place

If it makes sense for you, it's obivously fine. I just wanted to point out this style is quite uncommon.

18 replies

•Created by gsoutz on 3/15/2024 in #support

How to avoid passing props all over the place

Well there are people who like class and people who hate it. Not sure it's really bad, but I have never seen any solid-js code using the classkeyword. Not typing this is probably a reason to not use it. What is the benefit of using a class (compared to have just variables inside the component function like in every solidjs component)?

18 replies

•Created by gsoutz on 3/15/2024 in #support

How to avoid passing props all over the place

You are obviously free to put commponents local state in a JavaScript class, but it's not common to do so. Typically local signals and local stores are just local variables of the component. Maybe you don't use JavaScript class. I inferred that from your previous question where you were using JavaScript class.

18 replies

•Created by gsoutz on 3/15/2024 in #support

How to avoid passing props all over the place

One additional thing. You say inside component i create classes . Given your previous questions, I guess you literally mean the JavaScript class. This is very uncommon in solid-js. I wouldn't know how reactivity works with classes.

18 replies

•Created by gsoutz on 3/15/2024 in #support

How to avoid passing props all over the place

It's certainly not the common pattern when using solid-js. Splitting functionality in components is certainly more maintainable. My answer is maybe a bit too much about the basics, however I have the impression that it may be worthwhile for you to look again at the tutorial or maybe some other sample code of solid-js. In props you pass whatever the component needs. I can be anything; it doesn't need to be serializable. Strings, numbers, arrays, objects and functions are common props types. Note that props may be constant, but may be reactive (from store or signal). When implementing component, it's best to assume that everything can be reactive (eg. never destructure props or assign props to local variable). When having app split in components, it's true that passing everything by props is not great. If you have common state to share in between components, the context is a common way to solve that. It's quite similar to just passing data through global variables (like you asked in previous question), but it has few differences. You can have multiple contexts (for example one shared by all routes, and another one local to a certain route, just for the sub-components of that route). It's more composable than just global state.

18 replies

•Created by ivan on 3/8/2024 in #support

Issue subscribing to store changes

Thanks for the reply. You seem to be a big supporter for this pattern. Admittedly, it's great to have a simplified syntax for the setter function. My concern about that is readability and maybe performance. Having that createStore that doesn't create a store is not self explaining code. It also goes through the full overhead of creating a store. Looking at the code the overhead seems mostly about wrapping again the object for accessor. If this seems a commonly used, I think it would be worthwhile to ask for a feature request for a store helper function for exactly that purpose. It could skip re-wrapping and could be correctly named.

37 replies

•Created by ivan on 3/8/2024 in #support

Issue subscribing to store changes

It's the first time I see this pattern to create a new store on a subtree of another store to have a simpler setter for that sub-tree (and don't use the reader). It seems suspicious at first glance. Is it a common pattern? Is it documented somewhere that this is supposed to work? Will it work in next versions of solidjs? The proposed alternative seems more redable to me:

const setQuestion = setQuestions.bind(undefined, index)

const setQuestion = setQuestions.bind(undefined, index)

Anyway I'm just curious about that pattern and would like to know if it's commonly used.

37 replies

•Created by QWu4xYV on 1/30/2024 in #support

Understanding memoization re-running

Thanks

13 replies

•Created by QWu4xYV on 1/30/2024 in #support

Understanding memoization re-running

@bigmistqke do you have a simple explanation of why it doesn't work? To me it doesn't look like a lazy memo (in the sense of lazy evaluation), but just delayed creation until the first use. Does it matter if it's stored in a global variable or a local variable in a component?

13 replies

•Created by QWu4xYV on 1/30/2024 in #support

Understanding memoization re-running

I found this example quite hard to read. You seem to make a memo from the store and put that store in a value cache stored in a Map. This part is a bit convoluted and hard to follow. I made a simplified example here: https://playground.solidjs.com/anonymous/0c909400-ca65-445a-8d96-d396e519072c That being said, I don't really know why the memo stops being run after the 2nd update. General comments could be made, but it might be a bit off topic to the question. It's not good practice to make a memo out of the root object of the store, since you pay the price of the store (eg. proxy overhead), but loose the fine grained reactivity of the store (eg. if anything of the store changes, everything dependent on any part of the store will update). I recommend to use the store directly. If the initial idea of this structure were some performance considerations, it's likely doing the opposite of the intended.

13 replies

•Created by JCM on 12/19/2023 in #support

Avoid re-rendering toolbar in solid router 0.10.x

Not necessarily. It depends what id was given to the root div in the html page, which isn't visible in the code snippet above. The example was taken from the official router example in the readme, where it uses document.getElementById("app"). In my actual app it's document.getElementById("root").

5 replies

•Created by JCM on 12/19/2023 in #support

Avoid re-rendering toolbar in solid router 0.10.x

I might have posted this a bit early as I already found a solution to the question. I need to supply a root property to the <Router> component. For the example above, it looks like this:

function App(props) {
  return (
    <>
      <A class="nav" href="/">
        Home
      </A>
      <A class="nav" href="/users">
        Users
      </A>
      {props.children}
    </>
  );
}

render(
  () => (
    <Router root={App}>
      {routes}
    </Router>
  ),
  document.getElementById("app")
);

function App(props) {
  return (
    <>
      <A class="nav" href="/">
        Home
      </A>
      <A class="nav" href="/users">
        Users
      </A>
      {props.children}
    </>
  );
}

render(
  () => (
    <Router root={App}>
      {routes}
    </Router>
  ),
  document.getElementById("app")
);

5 replies

•Created by aryzing on 12/6/2023 in #support

How to clear a store?

This is what the new doc seems to recommend https://docs.solidjs.com/references/api-reference/stores/using-stores#updating-stores

9 replies

•Created by aryzing on 12/6/2023 in #support

How to clear a store?

I do setStore(reconcile({})) for that use case

9 replies

•Created by JCM on 12/4/2023 in #support

`reconcile` object to array mutation

No response hopefully means that I'm not doing anything obviously wrong. Given it looks like a bug to me, I went ahead and filed a bug report: https://github.com/solidjs/solid/issues/1973

3 replies

•Created by crowned on 10/30/2023 in #support

How to allow updating of elements instead of destroying and rendering the elements?

Admittedly, I haven't spend much time looking at the example, so I'm not really sure I understand the problem correctly.

But in the case that there are a 1001 elements to update, how do I make sure 1 specific element is updated before the rest.

Unless I misunderstand the problem, I don't think you should aim for that. The interface should visualize the data in a consistent way (eg. data-> UI). If you need to order the updates in function of importance or urgency, it's getting messy. Paging and/or virtualization should fix the performance issues.

61 replies