New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: Why are you using Solid's createMutable? #498
Comments
Sometimes the DX is more worth a negligible performance loss. The over subscription only happens in some cases, but Solid has been making progress on this (f.e. Array methods). |
Oh, if we're talking about build output though, we may as well use the most optimal output: plain signals and memos whenever possible. |
Yeah we are talking about build output. |
Yeah, we're definitely open to producing the more idiomatic output! However, from reading SolidJS docs, it seems like the only other choice is import { useStore } from '@builder.io/mitosis';
export default function MyComponent(_props) {
const state = useStore({
list: ['hello', 'world'],
newItemName: 'New item',
addItem() {
state.list = [...state.list, state.newItemName];
}
});
return (
<div/>
);
} Which currently becomes this SolidJS code: import { createMutable } from "solid-js/store";
function MyComponent(props) {
const state = createMutable({
list: ["hello", "world"],
newItemName: "New item",
addItem() {
state.list = [...state.list, state.newItemName];
},
});
return <div></div>;
}
export default MyComponent; I'm not super familiar with Solid's state management solutions, but it looks to me like far more complicated logic to convert this into a handful of How would this above example end up looking if it was idiomatic SolidJS? |
This is the most idiomatic way: import { createStore } from "solid-js/store";
const [state, setState] = createStore({
list: ["hello", "world"],
newItemName: "New item",
});
const addItem = () => setState("list", state.list.length, state.newItemName); You can put You can also do const addItem = () => setState('list', produce(l => l[l.length] = state.newItemName)); Or less optimally one of those: const addItem = () => setState('list', [...state.list, state.newItemName]);
const addItem = () => setState(produce(s => s.list = [...state.list, state.newItemName])); Which will update the whole list instead of just a specific position in the array. |
ah yes, alternatively we can also use signals too. what I like about createmutable is support for nested mutation, so similar to what we do for react, svelte, etc we could just have an output using signals (basically identical to our react hooks output except all access is a function call instead of a direct reference) const [list, setList] = createSignal([...]);
const [newItemName, setNewItemName] = createSignal("New Item")
return <div><input value={newItemName()} ... />...</div> this would potentially be the easiest path since we can reuse a lot of the logic for react hooks |
Yeah this is the easiest solution and I think that it's also slightly faster than stores although stores are more idiomatic. |
Asked questions in the SolidJS Discord, here's the thread https://discord.com/channels/722131463138705510/751355413701591120/1001192746301788180 We might want to try some of these options:
|
Should we not just use signals? What's the downside to the most simple/idiomatic approach used in solidjs's docs? Everything else here sounds more complex and deviates from the idea of "generate code just like a developer would write" for a given framework We should be able to just reuse all of our react hooks logic, just make sure all reads add a |
It is totally conceivable people can write all their state variables using const [foo, setFoo] = createSignal(...)
const [bar, setBar] = createSignal(...)
const [baz, setBaz] = createSignal(...)
// ...etc... Maybe less ergonomic than stores in various cases, but still legitimate and still an idiomatic option |
We have added support for |
I wasn't sure if I should open an issue about this but I saw that you are using Solid'
createMutable
which is not recommended and is intended mostly for easier transition from libraries with similar APIs. Other than not having read and write segregation it also leads to over subscription. Maybe you guys are aware of that already, just wanted to make sure.The text was updated successfully, but these errors were encountered: