File Structure in T3 Stack
hello guys i wanted to know where do we put types and what the folder structure of it like for example do you put them in components/NavBar/types.d.ts or do you create a root folder /types and if you have other ways to structure types i would like to know your opinion on this
20 Replies
Just put them in the components where you use them, until that feels bad, then move them
Why are you making a types file?? Ugh
I’ve hardly seen the need to have all of my types in separate files.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I unlisted this due to the pushback but you need it
https://youtu.be/86i8ZODqMlI
Theo - ping․gg
YouTube
React Folder Structure: PLEASE Stop Overthinking It
Just a casual reaction to my new favorite Youtuber 😅 WATCH ME LIVE ON TWITCH https://twitch.tv/theo
I need more keywords so REACT REACT REACT REACT REACT JS WEB DEV FILE FOLDER STRUCTURE PROJECT WEB APP JUNIOR BEGINNER NOOB SENIOR FEEDBACK WEB DEV SIMPLIFIED REACTION AAA
Idez KILLED it with this edit so give him some love.
Follow me on Twitte...
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
yO this vid is pretty nice, i know fuckall about "good" js folder struct lol ty! sorry to hear bout the pushback. it sounds like a genuinely helpful vid
actually let me revise my comment
if a typedef is being used in one file, it should 100% live in that file
im not sure ive ever seen an exception to this
How do you handle shared types, as in used by 3 or 4 components and the type could live with any of them? Isn't it harder to remember where you put them and start importing them from file A B and C than a single shared types file.
structure your project by feature/resource (ideally this maps 1:1 to db tables, not always possible irl of course so just use good judgment)
then it becomes obvious where shared types should live
That makes me go urgh a lot more mental load
how so
can you give an example
This is probably less of a problem with T3 than other stacks but let's say you use a 3rd party API used by the client and you have 3 components that use that API. You have manually typed the response all 3 components do a query to that same endpoint, where does the type live, do I have to make a service file just to have somewhere to stick the type, or can I just make my components and stick the type in a shared location.
I guess it's what the video says make the file structure what the project needs
There is no generic optimal structure I guess
If I have types for a component I don't stick them in separate file sounds like extra admin
/util/apiname.ts
put a wrapper around the api in there because you probably want that anyway
in case it changes
types can go there too
if it gets too big, make a folder i guess
or some people call this /lib
I also make components libraries where I have to export the types to an index file
It's super handy to just have them in one file and do
export * from '../types'
Almost every time I have this, it's because some component (we'll name it
C) needs props drilled from high up
Hierarchy:
If A and B only need C's props so they can pass to C, the props should be defined there and imported in A and B
If you have components that are unrelated, but the types they need are the same, maybe make a file to share that type? I think this case is pretty rareSlightly adjacent topic. Does anyone else use absolute imports, I feel like I'm in the minority I see everyone else use relative imports.
My rationale is no matter what my folder structure is I can copy imports from one place to another and never have to fix them. Nor do I have to think it is ../ or ../../ or ../../../
True
Absolute imports are dope and you should probably use them
We didn't do them in ct3a because of how many opinions exist around them
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I remember Rollup having issues with absolute imports, with regards to generated exported typescript types not working properly, looks like it is still an open issue 3 years on. https://github.com/rollup/rollup/issues/558
Looks like Jared Palmer's TSDX project found a work around though.
Unless you're making a tree shareable lib this isn't really an issue tbh but it's still interesting that some package managers have issues with them in the first place.
GitHub
Handle absolute imports relative to
basedir · Issue #558 · rollup...Hi there, What is your opinion about supporting a basedir option, and resolving all the absolute imports relative to that basedir? Sometimes it's handy to just write import '/consta...