Paulo Martins
Paulo Martins
TTCTheo's Typesafe Cult
Created by Paulo Martins on 7/7/2024 in #questions
About Theo's take of not destructuring props
Yeah, I'm doing it more as an experiment. I still very much prefer the spreading approach, but I'm gonna try without it and see how it works. Maybe there are some insights that could help with better prop definition in general. Some things I've been thinking lately are concepts like: "Is it interesting for the user of the component to have to know its inner workings? Or should it act more like a black box?", "What are the advantages of making a closed component vs a component with subcomponents that the user has to 'Lego'-it together", "When to use children prop vs creating another prop with ReactNode type" and "Should primitives be treated differently regarding their type definitions?". I know a lot of this depends on the use case, but I just want to have a mental model on what to do in each situation (perhaps make a flow chart also?)
10 replies
TTCTheo's Typesafe Cult
Created by Paulo Martins on 7/7/2024 in #questions
About Theo's take of not destructuring props
Hey! Sorry for the late response. So, I was thinking about this, and it may be correct solution indeed. Like, Using the "...rest" approach with destructuring may lead to some confusion on where the props are going when you type them while using the component. The only downside is that you loose the attribute syntax when you want to use those inputProps, but it makes sense. Gonna make an example below to better clarify what I'm saying, and gonna test using this approach for a couple weeks to see how it goes, but thanks for the help!
10 replies
TTCTheo's Typesafe Cult
Created by Paulo Martins on 7/7/2024 in #questions
About Theo's take of not destructuring props
Thanks for answering! I saw something like this in the example of how default values work from behind the scenes, in the React doc link I sent (the "Pitfall" section), and it's pretty much this, but the issue below persists
Warning: React does not recognize the testColor prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase testcolor instead. If you accidentally passed it from a parent component, remove it from the DOM element.
Basically, this happens because props has not only the attributes for input, but the new prop testColor as well, which is being passed to the <input> element even though it does nothing in this case
10 replies
TTCTheo's Typesafe Cult
Created by Paulo Martins on 3/7/2023 in #questions
WebSocket workflow for serverless with T3 stack
Yes, they seem like contradictory concepts But in this case, at least from what I gathered, Pusher is not serverless, is it? The conection/subscription between Pusher and the client is a breeze to make, and for the Next.js backend part, I can access Pusher's server trough it to modify it data that's then delivered to all subscribers It's like a serverless function contacting a serverful websocket service to change info
9 replies