How to avoid passing props all over the place
How cool is putting all your interface in a massive pile of one closure to avoid passing stuff around. Except maybe some reusable components. Markup content deeply nested in show when clauses.
16 Replies
Finally I want to ask about what are useful things to pass as props. Like can I pass a whole big object as part of a class with methods on it. I try to retrain from that and only pass serializable simple data, for easier testing or mocking purposes. Is that illogical or what?
Props are external component state. So avoid putting global or contextual state in props. It should not make too much of a difference for testing, we support wrappers in
@solidjs/testing-library.How cool is putting all your interface in a massive pile of one closure to avoid passing stuff around.do you mean like global state?
no inside component i create classes that contains the state of the app. like one big component for one big page.
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.
I guess I am at a prototype phase, where I don't care about boilerplate to make code maintainable. Or my "big" is not that big. I will stick to pile of nested tsx. Of course if I need a progress bar, i make that a component sure, but some shared functionality split into different but similar modes are inside my one big component.
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.no some class to keep some state around, it has props of signals, with helpful getters setters so no dealing with [get, set] logic.
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.yes class keyword, to organize common state. Why would you want to avoid it. To delegate some logic to place inside class instead of inside closure. Maybe the mutability is something to avoid at all costs, I can't think clearly.
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)?Yes and yes, the mutable signals and mutation logics are all wrapped in the class, I don't create signals inside component's closure, but create an instance of the class, that has signals in it. with useful getters setters.
Then maybe some memos inside component's closure.
If it makes sense for you, it's obivously fine. I just wanted to point out this style is quite uncommon.
class gives you this
my_object.my_signal = true
and const x = createMemo(() => my_object.my_signal)
ofcourse a decorator that writes this property templates would also be useful hence my second question.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).Oh, by second question I meant my second post, anyway thanks for the info.
But as you said I feel a little bit eerie passing that class with signals and props as a prop down.