Echo JS 0.11.0

<~>
timoxley 2726 days ago. link 6 points ▲ ▼
Magic strings create an implicit dependency between components. Implicit dependencies can make understanding how a system interoperates and the relationship between components more difficult. Where does this action come from and who else cares about this? These two "save" actions have the same name, but are they actually the same? Magic strings used like this are kind of like globals.

Rather than using magic strings, exporting and consuming a constant from outside the file it's defined in requires creating an explicit and directional relationship between the definition & the consumer: `import { CONSTANT } from './place'`.

The boilerplate is undesirable but I think showing explicit, directional relationships between files via require/import is more valuable for the overall cohesiveness of the system than the few lines of code you save.

I agree with the article that when constants are defined and consumed in the one file, constants are perhaps overkill, though maybe there's benefit to maintaining the same pattern for both internally and externally consumed constants.

Also agree with the overall sentiment of the article, should definitely be questioning and evaluating the cost benefit of best practices for our specific use-cases rather than blindly cargo-culting the dogma.

Replies

tracker1 2726 days ago. link 3 points ▲ ▼
I'll often take it a step further than that...  since I tend to break up my actioncreators and reducers by feature and that feature is within a redux subtree, I may 

    import { SAVE, SAVE_SUCCESS, SAVE_FAIL } from './constants'

but underneath it is likely...

    export const SAVE = 'promise:feature/save';
    export const SAVE_SUCCESS = 'resolve:feature/save';
    export const SAVE_FAIL = 'reject:feature/save';

in this way I can have extensions in redux to handle 'promise:*', 'resolve:*' and 'reject:*' generically, in addition to or before the resolver.
bevacqua 2726 days ago. link 2 points ▲ ▼
Also worth noting that the article doesn't address the benefits listed in a link he provides near the end, namely:

- It helps keep the naming consistent because all action types are gathered in a single place.
- Sometimes you want to see all existing actions before working on a new feature. It may be that the action you need was already added by somebody on the team, but you didn’t know.
- The list of action types that were added, removed, and changed in a Pull Request helps everyone on the team keep track of scope and implementation of new features.
- If you make a typo when importing an action constant, you will get undefined. This is much easier to notice than a typo when you wonder why nothing happens when the action is dispatched.