Quoted post unavailable.
Thanks.
Delightful React file/directory structure
31–40 of 53 posts
Re: Delightful React file/directory structure
#32Can we please stop describing technical things using feelings-based words? It's foppish, it makes tech sound really really disingenuous and fake, and it cheapens the words as well.
"Clean," "well-organized," "atomic" ... all adjectives, all descriptive, zero emotion
Re: Delightful React file/directory structure
#33Can we please stop describing technical things using feelings-based words? It's foppish, it makes tech sound really really disingenuous and fake, and it cheapens the words as well. "Clean," "well-organized," "atomic" ... all adjectives, all descriptive, zero emotion
Whenever I see the word 'beautiful', I often find that thing is not beautiful. But it gets used, a _lot_. The only explanation I can come up with, is they are simply assuming that you are incapable of forming your own thoughts, and need to be told what to feel.
Re: Delightful React file/directory structure
#34Can we please stop describing technical things using feelings-based words? It's foppish, it makes tech sound really really disingenuous and fake, and it cheapens the words as well. "Clean," "well-organized," "atomic" ... all adjectives, all descriptive, zero emotion
"Clean" is used in this blog post.
I think it is kind of weird to ask folks not to use feelings-based words when the point here is that they are describing their opinions.
When Josh writes
> Well, there is no one “right” way, but I've tried lots of different approaches in the 7+ years I've been using React, and I've iterated my way to a solution I'm really happy with.
how would you prefer he have phrased it? The iteration has ended in joy for him. Should he not express his joy? Sure, he could express in a technically-phrased way why it causes him joy (maybe tighter iteration loops, maybe easier generation of value, etc. etc.) but then he'd have to prove those things, wouldn't he?
It's hard enough to just get your opinions out there without also having to prove each one as if you were declaring an ultimate statement of fact.
Re: Delightful React file/directory structure
#35There are some things I really like about this, and some things that can shoot you in the foot.
Like:
- Having more than one component in a file. A lot of complex components can be made simpler by breaking then into many smaller, temper components. A lot of these helper components are too specific to warrant generalized use. Adding a new file for each one (especially if they're only 3-5 lines of code) clutters the code base, so keeping them in the same time where they're used makes sense. You can always pull them into a separate file later.
- Not making everything "index.js". That really makes it more difficult to keep track of what's what code is where.
Dislike:
- using indeed.js for experts. This makes it easier to accidentally add circular imports, and much harder to track them down.
- putting all components in a components/ directory. This is fine for smaller apps, but it starts to get unweildy once you add more features, teams, or team members to the repo. This is especially true if you use redux, Apollo, and React-router (or any of their competing libraries). Selectors, reducers, GraphQL queries, get spread across the code base, and it becomes difficult to teach down which component rely on what selectors (for example). This starts to bog down onboarding and cross team collaboration since ownership becomes more difficult to define. You end up with spaghetti code pretty easily.
Re: Delightful React file/directory structure
#36Can we please stop describing technical things using feelings-based words? It's foppish, it makes tech sound really really disingenuous and fake, and it cheapens the words as well. "Clean," "well-organized," "atomic" ... all adjectives, all descriptive, zero emotion
Are there useful technical qualities that don't reduce to feelings?
Re: Delightful React file/directory structure
#37Kinda wish Josh would mention how he structures his tests in his projects. Something I'm currently struggling at work is that within our code repos, the pattern that everyone seems to copy is mimic the src/ directory for the test/ directory, rather than co-locating tests along with components. This means a structure for components: src/ components/ Button/ Button.tsx Is just copied ad-hoc for tests, so we get this: t…
There are several good reasons to keep your test code in a completely separate directory (or "project")
1. Sometimes you want to do some experimental refactor in your application. This might break a lot of tests (cause them to not compile). But you first want to play around with the new change before committing to it and updating all your tests. If your test code is in the same project then the compiler errors will prevent you from doing this.
2. Your test code and application code usually need different dependencies. You don't want your test code to accidentally call functions from some helper library, and you don't want your application code accidentally calling functions from some test framework. If you have a shared list of dependencies and a large team then this will inevitably happen.
3. You don't want your application code to accidentally call helper functions from your test files. If you mix them in the same project then with a large team this will inevitably happen.
4. For code navigation and things like IDE "find usages", it is better to not be flooded with results from test code, in order to be able to focus on discovering how the code works. (Sometimes you do want to be taken to the test code which is why good IDEs allow you to choose to toggle on/off cross-project navigation).
5. Bonus: Sometimes you may want to write your test code in a different programming language then your application. This is uncommon but does happen. For example a C library with a test suite written in C++. Or a webapp backend with tests written in a scripting language using selenium. In these cases you have to have a separate project, and so for consistency you do it as well also for tests that use the same programming language.
I think the last point is actually the most important: it helps formulate the understanding that your test suite should be viewed as its own separate and independent program, not inherently tied to the library code that you are developing. This leads to two insights: 1) there's no reason why you couldn't have more than one test suite to test your library (possibly developed by different teams). 2) more interestingly: you should be able to take your test suite, and run it against a different implementation of your library. This makes sense for something like a test suite for a filesystem or SQL database. But even for your custom library, if you ever need to do a rewrite, or port to a different platform/language, then being able to take your existing test suite with you will be invaluable.
Re: Delightful React file/directory structure
#38Earlier quoted context omitted.
I think people do the "separate directory for tests" thing because test runners have, in the past, shipped with a default configuration to target a test directory, rather than match test files by suffix. Colocation of test files is the hands down winner and encourages the writing of tests. When you're making a change to a code file, you probably won't think to scour the codebase for relevant tests. If you see the tes…
When you make a change to a code file, you should run your tests. Why else do you have them? A test failure should result in you going to fix that or, if appropriate, change assumptions of the test. I don't see how it is harder to add tests either.
What about changes that don't cause test failures? A really quick one I can think of is a pure addition. Lets say you have tests for Feature A in 3 places. You add a thing to Feature A, and find 2 places where Feature A is tested, add tests to those, feel like you did your due diligence and move on. Co-located tests would fix this problem
Re: Delightful React file/directory structure
#39Kinda wish Josh would mention how he structures his tests in his projects. Something I'm currently struggling at work is that within our code repos, the pattern that everyone seems to copy is mimic the src/ directory for the test/ directory, rather than co-locating tests along with components. This means a structure for components: src/ components/ Button/ Button.tsx Is just copied ad-hoc for tests, so we get this: t…
That's exactly what Deno does [0] in its standard library. Colocate tests with code. It just works.
Some people also like to go further the bad way and group code by type rather than feature.
src/
components/
componentA.tsx
componentB.tsx
hooks/
hookA.ts
hookB.ts
tests/
componentA.test.tsx
componentB.test.tsx
Re: Delightful React file/directory structure
#40I would avoid default exports at all cost.
All the tutorials which I have been following always default export it. Whats the reason to avoid default export ?
Not OP but I avoid default exports unless I need to do a lazy import. For me, there's a few reasons: consistent naming, easier importing, encourages importing what you need, avoids weird situation where you do both a default and named import.
Consistent naming: since I named the exported thing, that's what the consumers will call it as well unless they go out of their way to do `import { X as Y } from '...'`. This is useful because it helps ensure all consuming code looks similar at least in it's usage of modules. More familiar code is easier to read and reason about. It's also useful for looking up usages of something. I know I can run $IDE's version of "Find Usage" but sometimes it's easier to just Ctrl+Shift+F > X.
Easier importing: If I have something exported as X then I go to a module that isn't using it and I type X, my editor will suggest I import it from the appropriate module. This _can_ work on default exports but only if you use the same name as was used internally at the point of definition. That kind of defeats the benefit of default imports where you can use whatever name you want without hassle and it's your responsibility to make sure you match the names correctly.
Encourages importing what you need: when you default to named exports, you default to pulling in the bare minimum to do the job. Consider the opposite case. Someone imports some monolithic chunk of code as a single object then does `library.thingIWant` with a bunch of different things. Now you've got a larger possible space to look at when trying to load all of the context of a file in to your head. This is also useful for tree shaking. Assuming you've written your code in a well-defined manner and are using a smart build system, it can more easily eliminate dead code because it knows you never import certain pieces of a module. This applies to both your code and code from third-parties.
Both default and named imports: This is common when working with React. You'll see `import React, { useState } from 'react'` or similar. I don't have a rational answer for this but it rubs me the wrong way.