I Tried a New Pattern in React

🚀 Project React → cosden.solutio...
Join The Discord! → discord.cosden...
VSCode Theme | Font → Material Theme Darker | Menlo, Monaco "monospace"
In this video I will share with you a new pattern that I've recently applied to a project in React. This is a pattern that I'm not 100% sure about, and that I expect it might break at some point in the future. But for now, it seems to work fine and solves my problem nicely! That is the pattern of using directly the type of the return function of data in React components!

[@braidofelipe]

Create Interfaces, you can create a lot of small interfaces with each piece of the result you need, and them create a "master" interface to extends all the others. Your function can be set to return the interface type and each component can be set to receive just the interface with the properties are needed

[@byAdnan]

What you can do is to create a Contract that both the Provider and Consumer use. You define your Contract as something like "RoutineResult". Your Provider is for example your "getRoutineVersionForDate" and it is forced to return anything that satisfies the Contract. Your Consumer is for example your Component which also is forced to handle input in the form described by the Contract. This way ensures that your Consumer is no longer tied to the actual implementation / provider and thus they do not know about each other. You also ged rid of that repeated Awaited typing. What I like to do is to create the Contract using Zod / Yup or something else to also provide a Schema which I use to Validate my Output and Input data so that I can react to invalid data on runtime side

[@DemanaJaire]

That sounds interesting. Would you mind sharing some minimal example?

[@dieguitto08]

That pattern is commonly used for functions coming from third parties libraries where the type definition is not clear or defined, hence this is a good solution to infer the type out of it. From my point of view you have 2 solutions, either you create multiple interfaces to define the different types and then add all of those into a “main” interface so you can use them in the different components or you could use something like zodiac schemas, to validate the data types are correct during runtime and then infer the different types out of the schemas so you can reuse them. Mainly both solution are dependent of a multiple data types that are link to a master data type, the advantage of the second solution is that you make sure the data gets validated before propagating down the children components

[@SkillR1]

Looks like you are holding a lot of data when you don't need all of it at the same time For each routine you are holding all its items, which also holding all of its entries Maybe you could split that into multiple API endpoints, and ask for the items for specific routine only in the place that you need it react query is already handling all the caching for you(in case you'll need again the items for already-viewed routine for example).

[@NikhilPatel-bq7ck]

This also one the approach and there one more declare small interfaces and assemble them to create a master one now keep all of them into type. ts under that feature now only use those type as per need and one can use extract, omit according to the need. Also it's a good practices to define function types under type.ts and just use it so that actual functional codes won't have readability issues.this way I don't have to touch if I change function name only if there is a type change you will do it in type.ts rest it will be just used so no need to worry

[@rometpastak1]

Can we also use context in this situation, so we don't have to pass props to these components, and get props from custom context hook instead?

[@tusharjain9701]

Context don't work with RSC. However tanstack query can be used here to avoid props drilling

[@zush2305]

This is pretty interesting, I often find myself stuck on simple problems specifically related to types because I keep thinking about future proofing, I should take up the mentality to loosen that up and embrace the fact the future changes is okay to happen and doesn't mean that the code is bad. I am wondering why wouldn't you create a global interface for the routines and for each component use "Pick" and choose what you need from that global interface.

[@spryzenthehonerone]

introduction icon was awesome

[@mcsoud]

Have you considered using typescript generics for this problem? I don't think I have a grasp on the big idea of the problem but if it's the type that is the problem you could just make it a generic I guess

[@baller_remorse]

Cosden Solutions you must watch your health

[@srt4baby24]

what do you use to record these videos?

[@kutukov2000]

I need more code review 🥺 please

[@den9943]

Clickbait 😉 It's not a NEW Pattern. It's a common feature in TypeScript. We've just inferred the result type of our function. We can also do the same with props in a component: ComponentProps And with arguments of a function: (...args: Parameters) => { const [a, b, c] = args; }

[@USPSLaura]

I have questions do you prefer using nodejs for backend or using services like firebase or aws

[@lllXchrisXlll]

This question doesn't make sense. Nodejs is a runtime. You can host a nodejs based application in f.ex. firebase or aws. They are not mutually exclusive.

[@USPSLaura]

@@lllXchrisXlll it makes sense because you can build a fullstack application without hosting a fucking node Js app

[@TianYuanEX]

Dude what are you waffling about, how do you make a backend using aws?

[@USPSLaura]

@@TianYuanEX 😢

[@USPSLaura]

@@TianYuanEXhow long have you been on coding, you need to understand difference between hosting your node Js app on aws and using aws service as backend, sometimes you might want to save yourself the stress of having to have separate code and separate file location for your backend