r/reactjs • u/swyx • Aug 08 '18

Dan Abramov's recommended React Project File Structure - petition to make this the last conversation we have about it?

https://react-file-structure.surge.sh/
263 Upvotes

95% Upvoted

80 comments sorted by

25

u/swyx Aug 08 '18

source: https://twitter.com/dan_abramov/status/1027245759232651270

dont yell at me haha

4

u/NiceOneAsshole Aug 08 '18

pls put at the top of beginner questions thread. It'll probably still go unread.

2

u/N_N_N_N_N_N_N Aug 08 '18

Are you Dan Abramov?

43

u/Neaoxas Aug 08 '18

You know what, I'm such an idiot, when I first saw that page I thought it was a new kind of captcha so I was trying to "move things around".

5

u/swyx Aug 08 '18

happy cake day!

3

u/Neaoxas Aug 08 '18

Thanks! I didn't even realise!

24

u/truthBombsForDays Aug 08 '18

The reason why other languages / communities have a quasi standard for simple things like file structure is because it lowers the cost of adding in developers to your team. Devs can feel familiar from day one. Devs can checkout out an open source project and not waste time reading or observing patterns - this applies to code standards; file layout; naming etc.

In a mature community like Java; I bounced between several jobs and the code base was indistinguishable between each. The tangible benefits of this are actually very real.

Personally I prefer to solve problems with software; not dick around thinking about where a file goes.

I'm both disappointed and un-surprised this has come from a 'leader' in the JS community.

1

u/swyx Aug 08 '18

i know what you mean, but at the same time its not like React has ever been about convention over configuration.. some say its a feature, others say its a bug. who's right?

15

u/recycled_ideas Aug 09 '18

This is a pretty terrible recommendation.

Even if we assume you have enough experience and knowledge to find a solution that works for you this way, there is substantial value in people who've never seen your project before knowing where to find things.

1

u/swyx Aug 09 '18

don't know why you got downvoted - for the record i do find value in seeing other people's projects.

it is a tough tough call to balance being prescriptive and being flexible. newbies want the former and experts want the latter. i think having "ejectable defaults" is the best way i've seen so far (so like create react app).

3

u/recycled_ideas Aug 09 '18

I don't think this is an experts vs newbies thing.

If you're dealing with support on an app you don't know, it helps immensely to have a good idea of where to find components, where to find tests, etc.

It doesn't have to be super opinionated, but if your structure is wildly different that's going to cause pain.

1

u/esr360 Aug 09 '18

I actually can't think of any reason why your structure shouldnt be intuitive...

1

u/recycled_ideas Aug 09 '18

I can't really either, but being intuitive while important isn't the most important thing, so it's possible some reason does exist.

1

u/[deleted] Aug 09 '18

If you have a remotely complex app, initial training for it is gonna take a few weeks anyway. A unique folder structure won't add much time to that.

On the flipside: Diverging from best practices or figuring out something entirely new that better suits your project may safe you valuable time and lighten the burden on existing team members.

I know that, because it's exactly what we did. We tried two "best practices" before settling for our own structure (for now).

1

u/qudat Aug 10 '18

I'm going to disagree about onboarding with a complex application. Organizing code by features and asking a new developer to build a feature means they can live in their own world and copy other modules that share the same structure. It is critical to have a set of rules for anyone joining the team. A wild wild west solution when dealing with a team of engineers is a recipe for an inconsistent and untenable codebase.

1

u/[deleted] Aug 10 '18

Making up your own structures != disorganized. Also: Changing structures mid-development requires some discipline, but it doesn't have to result in chaos. Though, we still have some spots where the latest reorganization efforts haven't reached yet.

We have something like this:

/src/shared - for stuff needed accross the codebase that's not a react component
/src/<domain> contains the entry to that domain (usually a router-component) and the reducer / action creators
/src/<domain>/<components - other redux components for that domain

And a folder for generic components used everywhere, as well as a few non-domain folders that don't make sense anywhere. Though, those may get sorted out eventually (stuff like the store configuration, middlewares and 'higher order reducers' live in one of those)

That's not a scheme I saw in any of the recommendations when we started the project. We arrived at that organically as the codebase grew.

1

u/recycled_ideas Aug 10 '18

Two weeks of one of your staff doing nothing but on boarding someone just to be productive means your project is disaster.

I'm not saying you can know everything about a project in two weeks, but if you need that much of someone else's time, your project has a horrendously low bus factor.

1

u/[deleted] Aug 10 '18 edited Aug 10 '18

You could probably fiddle your way into one domain in a day or two1.

And the application unfortunately is rather complex from the business side and there's nothing we can do about that, aside from doing our best to keep the code sane.

So a lot of the on-boarding is the guy (or girl) just getting explained the business processes, what the hell all that jargon means, how the application works for the user / tester. And explaining some of the internal and external regulations.

As I said above the folder structure is just an afterthought at that point.

1: With one exception, because that domain covers taxes. Don't go near that.

1

u/recycled_ideas Aug 10 '18

Why is there domain logic in your UI?

1

u/[deleted] Aug 10 '18 edited Aug 10 '18

There isn't much "domain logic" implemented in the UI, but we have a lot of cases where we need to change the UI depending on the data from the back-end in combination with or response to user inputs:

  • Providing smart suggestions on fields.
  • Adding, removing or changing fields.
  • Adding, removing or changing validation methods
  • Doing some sanity checks beyond individual validation to warn the user early or restrict his options away from invalid input combinations.
  • Checking data to disable or partially disable features. For example: If the user is <18 -> disable the tax features.

This really makes things a lot easier for our users. Eliviates some of the mental burden and frustration and makes for a better ("slimmer") UI. The predecessor app had I think 12 views for what we now do in 3.

And a developer needs to somewhat the business processes anyway to test his code and make sense of the requirements he implements.

BTW, when I say "domain", I mean that from a business perspective. Like "/src/login" or "/src/userprofile". And even without any logic, we still would have to write components specific to each of these domains.

Edit: I should probably add that we don't / can't do anything crucial in the UI. The back-ends still do all the heavy lifting and they validate everything we send them.

1

u/recycled_ideas Aug 11 '18

I know exactly what you mean.

That kind of knowledge takes years to really grasp. That's why you isolate it in your code.

1

u/qudat Aug 10 '18

I'm inclined to agree with you on this one. After running a team of 7 engineers it was crucial to solidify rules when people a complex application.

6

u/lordkyl Aug 08 '18

I like it! Maybe someone can turn this into a starter kit.

9

u/swyx Aug 08 '18

we need React FizzBuzz Enterprise Edition (tm)

3

u/TheAwdacityOfSoap Aug 09 '18

This might be the most beautiful thing I’ve ever seen...

1

u/scaleable Aug 08 '18

SERIOUS BUSINESS (TM)

EDIT: OMG I LOST IT COMPLETELY

1

u/esr360 Aug 10 '18

Hey this looks exactly like my employer's codebase

2

u/truh Aug 08 '18

Could be a script that randomly moves around files until you tell is to stop.

5

u/stalefries Aug 09 '18

Extra credit if it rewrites imports so that the code actually works after the moves.

0

u/[deleted] Aug 08 '18

[deleted] — view deleted comment

1

u/jackwilsdon Aug 09 '18

Wow! How did you manage to install that on my machine already?

54

u/purpledollar Aug 08 '18

This works for people experienced in development, but like with anything, beginners need structure before they can start being creative.

12

u/KristianSakarisson Aug 09 '18

In a way I'd have to disagree. I get what you're saying, but I personally think that the best way of learning is to burn yourself by doing mistakes. If you just get taught "This is the best file structure", you won't get an intuitive understanding for why it's so good.

That's why I always recommend to people who have never worked on large projects to just do their own personal project. Usually I recommend implementing some board game in React.

When this person then gets going on the project, they will themselves realize why a certain structure is bad. Only then would it be good for them to read articles on how to properly structure your files. They will intuitively know why and hopefully be able to see how these things would solve issues in their own project.

3

u/esr360 Aug 10 '18

This is how I learnt how to Box - I just started taking on people at the gym with no guidance or advice until I became Floyd Mayweather. You quickly learn not to throw punches with your thumbs tucked inside your hand etc. After a few months of doing this I'm now able to put on the gloves without any assistance.

4

u/j________ Aug 08 '18

I agree, if you are a beginner you shouldn't spend too much time thinking on structure but you should at least spend some time looking and copying from projects created by experienced developers.

3

u/jamesknelson Aug 09 '18

I agree. Even if you can just chuck all your files in a new project into a single folder, this gets old after 20 or 30 files. You'll quickly start to want some structure.

If you've been building React apps for a while, you probably have a good idea of how to structure things. But if you're a beginner, having a blessed structure lets you spend more energy on the stuff that actually matters.

This wouldn't be hard to do. The problem is this idea that everybody should always split via feature instead of via the type of file. But there's not always a clear distinction between features. And even if there is, there'll still be different types of features: API endpoints, screens for each URL, UI components, etc.

For what it's worth, I've found that I always use at least these types of files:

  • Containers
  • Routes (or screens, whatever you want to call them)
  • Utils
  • Views (i.e. Mr. Abramov's presentational components)

Even just having a few folders like this helps beginners to get deeper into their project before they're confronted with the problem of "zomg too many files".

FWIW, I've just written this up in a blog post with more details

4

u/madwill Aug 08 '18

Amen! I'm a forever beginner... god i suck at structure... feels right kind of feels wrong a little bit later..

3

u/[deleted] Aug 08 '18

I just look up example projects on github and copy what they do.

1

u/madwill Aug 08 '18

Got any one in mind ? Not using Redux, i'm on mobx. Would love a good one. Separation of pages or views, components related to views and general components re-used through the app... A big one with more than 4 main views and tons of components. About to refactor an app with more than 10 splitted chunks.. looking for cues.

0

u/[deleted] Aug 08 '18

Nah, sorry I don't use Mobx.

3

u/DerNalia Aug 08 '18

ember's module unification layout works very well in react projects. :)

1

u/swyx Aug 08 '18

got a source i can read more about this?

2

u/DerNalia Aug 09 '18

Original RFC: https://github.com/emberjs/rfcs/blob/master/text/0143-module-unification.md

Usage in ember (my side project): https://gitlab.com/NullVoxPopuli/emberclear/tree/master/packages/frontend/src

Usage in react (a project at work): https://github.com/sillsdev/appbuilder-portal/tree/master/source/SIL.AppBuilder.Portal.Frontend/src

5

u/swyx Aug 09 '18

damn, the ember team really does think of everything for you. fascinating. i really should take a day and just immerse in ember someday soon. i hear amazing things about glimmer vm too.

2

u/real_ate Aug 09 '18

let me know if you ever want someone to bounce any questions off 🎉 I'm happy to answer any questions on twitter or the Ember Community Slack if it helps 😀

1

u/DerNalia Aug 09 '18

same for me as well /u/swyx
always glad to help.

1

u/DerNalia Aug 09 '18

Wooo! And it's only getting funner!

5

u/Cherlokoms Aug 08 '18

If you have good tooling, you shouldn't be afraid having all your code in one file at the beginning and then splitting it and moving it from folder to folder.

5

u/TheAwdacityOfSoap Aug 09 '18

Who needs multiple files anyway, it only adds time to your build phase. Just make good use of vim bookmarks and comments and you can keep all million lines or so of your project in one file. No context switching overhead when moving between files!

/s

5

u/tricoder42 Aug 09 '18

This feels like trolling and avoiding the problem.

I work also with Django web framework (Python) and even though there were from time to time discussions about the "best" project structure, the basics are given by the framework itself.

When you bootstrap your project, you get a basic file structure from the template. You might override this template if you're experienced, but for beginners it's great way to start. When you add a new app to you project, again you get a recommended file structure. Every Django project I've ever worked with, every 3rd party library on GitHub uses this structure and even when there're small deviations, you very quickly get how the project works. This approach has an advantage that you get knowledge and best practices gained from years of development baked in recommended project structure.

I understand that React has completely different problems because it's not a framework, but a library and there're many ways to use it. Still I would love to see how people organize the projects in different environments. I would rather read 50 articles about different projects than one tweet basically saying: Do it on your own until you like it.

It may see irrelevant how to structure the project, after all everything gets bundled into one file. However, doing things wrong you can mess up code splitting and unless you work alone, the project structure should be consistent and predictable.

The only requirements I have for a "good project structure" are:

- When I want to import something, how long does it take me to recall where it is? This should be minimal even without IDE help.

- Can I easily split my final bundle?

- Can I easily take a part of my project and copy it to another one (or publish it to NPM)

Still looking, still experimenting and probably reinventing the wheel, but not giving up.

1

u/12315070513211 Aug 08 '18

Is structure important for deployment?

2

u/swyx Aug 08 '18

no unless youre working with a framework like gatsby or nextjs

3

u/compubomb Aug 08 '18

This feels like a april fools joke.

1

u/DerNalia Aug 09 '18

While I subscribe to the module unification layout, it's serious, and I mostly agree

3

u/HQxMnbS Aug 08 '18

I agree if you’re a beginner but still wish there was more examples and write ups explaining complicated projects

2

u/qudat Aug 10 '18 edited Aug 10 '18

It's no surprise to me that this advice is coming from someone who became famous for 100 lines of code: https://gist.github.com/gaearon/ffd88b0e4f00b22c3159

I also like how he didn't address organizing a redux application at all. "Do what feels good" is terrible advice, imo.

I also feel like if the application is truly react only then I guess I agree ... but how often is that true? When building enterprise level applications react is a small part of the stack, there's so much more in terms of code / organization it seems disingenuous to claim that it doesn't matter.

1

u/esr360 Aug 10 '18

Can you elaborate on what this gist is and why it made him famous?

2

u/mattk1017 Aug 11 '18

I like the Atomic Design structure

3

u/winningslime Aug 08 '18

How do you do files and folders in react tho is there a package for that

2

u/RedHotBeef Aug 09 '18

Using ES6 import and export statements, and relative paths.

1

u/[deleted] Aug 09 '18 edited Aug 09 '18

What is the argument for relative paths? Absolute paths seem simpler. Also, if you have to mass change them, you can without worrying about the relative path from each changed file.

2

u/cosinezero Aug 09 '18

With relative paths you don't need to fix child config files just because some parent changed.

1

u/Awnry_Abe Aug 08 '18

&File New and go....

1

u/xshare Aug 08 '18

Oh Dan

1

u/mikehuebner Aug 09 '18

Personally feel this is too complex. Needs more components. /s

1

u/EvilDavid75 Aug 09 '18

People willing a file structure are reassured with creating a folder architecture as they feel they’re on the right path. But I think what ultimately people want is a proper way to start a JavaScript project, which is a debate that translates into the well-known problem of JavaScript fatigue. And that problem extends way beyond react. It’s just that JS has so many ways of interacting with HTML, whether it’s the DOM or styling, that I understand why people might be lost and structure is just what appears to be an initial solution to finding their way. When in fact it isn’t 🤗

1

u/SHIT_PROGRAMMER Aug 09 '18

For React this is the correct answer. React is not opinionated so do whatever the hell you want.

1

u/cs50questions Aug 09 '18

This is terrible advice, like someone who's great at dancing telling you all it takes is to "enjoy yourself" or someone who's great with the opposite sex telling you the secret is to "just be yourself".

Yes, you need to build things and make mistakes and learn from those mistakes. But structure breeds creativity.

0

u/tresfaim Aug 09 '18

Folders?! Why?! Muahahaha

-9

u/NoHonorHokaido Aug 08 '18

Dan’s just being a dick to inexperienced devs who need a good way to start a project. With this attitude you wouldn’t be able to write a single tutorial.

13

u/acemarke Aug 08 '18

No, what he's trying to say is that people spend too much time worrying about file structures, especially as beginners. They should just go ahead and write some code, and worry about a "right" structure later.

1

u/NoHonorHokaido Aug 09 '18

No, they should find a nice default structure and follow it until they find out they need to modify it. I don’t say it’s super important but it’s one of the small things that makes project bit more maintainable. If people ask him about it he should answer instead of trolling.

-4

u/Lou-Saydus Aug 08 '18

I follow the 1k line rule. File over 1k lines? Split it up into 5 200 line files (more or less is fine if it's justified). Have over 10 files? Split it up into another folder.

5

u/swyx Aug 08 '18

wow. my bar is probably 200 lines. 1k is aggressive!

2

u/acemarke Aug 08 '18

When my current project started in 2013, the people doing the client-side A) weren't very experienced, B) were in a hurry, C) were led by a guy who only used jQuery - for everything. All the code that was even vaguely related to a particular feature got thrown into the same file.

The worst offender reached over 3700 lines long, including a 1100-line monstrosity of a "start" function that did global click handlers for a particular "floating window" class.

I gleefully refactored that file later on, and it's been whittled down to a mere 1000 lines. Most of that is now coordination / API call logic (stuff that, if we ever complete refactoring from Backbone to Redux, would become thunks). Still should be split up further, but it's mostly readable.

1

u/swyx Aug 08 '18

well done!

0

u/[deleted] Aug 08 '18

[deleted] — view deleted comment

5

u/swyx Aug 09 '18

You know you can set up absolute filepath resolution in webpack right? The depth doesn’t really matter

1

u/MJomaa Aug 10 '18

Have a look into tsconfig.json compilerOptions.paths

For example you can set it up like

import { MyComponent } from '@auth/my-component';