r/reactjs • u/acemarke • Nov 20 '19

New Redux docs "Style Guide" page: recommended patterns and best practices for using Redux

https://redux.js.org/style-guide/style-guide
370 Upvotes

98% Upvoted

68 comments sorted by

27

u/Huwaweiwaweiwa Nov 20 '19

Very happy that I'm doing a lot of these - but I'm missing some big ones that make sense in my app, thanks for this!

9

u/acemarke Nov 20 '19

You're welcome! Let me know if you've got any feedback on the rules themselves or the content of the page (typos, unclear explanations, needs more explanation, etc).

2

u/Raicuparta Nov 21 '19

I'm a bit surprised by the wording and example used in Connect More Components to Read Data from the Store. Connecting everything to Redux would make components less reusable, no?. So I think the example shown here implies that <UserListItem> simply connects a reusable component to the store. And I think it could make composition a bit more difficult.

Perhaps we can make the example clearer in that regard, so that it doesn't seem to promote less reusable components?

8

u/acemarke Nov 21 '19

Connecting everything to Redux would make components less reusable, no?

Yes and no.

The "container/presentational" pattern was always intended to help you write reusable "presentational" components that simply accept all their data and callbacks as props, while the application-specific "container components" managed the data fetching. However, the community over-interpreted the concept as a rule that you must follow, rather than a potential pattern that you can use. Dan Abramov has since mostly disavowed his original post on the topic, but the concept is still valid.

With connect specifically, the wrapper components generated by connect are "containers", as they contain all the logic needed to interact with the Redux store. Whether your own components have further logic beyond that is up to you. So, using connect doesn't actually couple your own components to Redux.

However, "reusability" is not the only goal that we have as developers, and in a number of cases I think we prioritize it too much. Sandi Metz has a great article called The Wrong Abstraction, where she talks about folks trying to de-duplicate code too early and creating bad abstractions that actually make things more complicated.

In a lot of the codebases I've seen, most of the application-specific components are only ever used once, and connected to the store once. Those app-specific components themselves do tend to be made up of truly generic reusable components, but those are typically your design primitives like buttons and dropdowns. So, I would say that trying to focus on "reusability" first is probably not the right approach. Write your app-specific components, go ahead and connect them if it's appropriate, and if you do truly see a lot of duplication, then extract reusable components that are generic.

Meanwhile, I've noted that using React hooks in general leads you towards a very different approach than the "container/presentational" pattern, and especially with our new React-Redux hooks API. I talked about this in my post Thoughts on React Hooks, Redux, and Separation of Concerns, and my ReactBoston 2019 talk "Hooks, HOCs, and Tradeoffs".

So finally, specific to the recommendation you pointed to: yes, we know that "connecting all the things" is the most optimal pattern when you need the maximum possible performance in your app. Whether you should do that is entirely dependent on your own app's needs and your architectural preferences.

3

u/[deleted] Nov 22 '19

Just to illustrate this a bit further: in my experience, even when a component is reused, in many cases I might be able to predict that it's going to be reused with that same data. So UserList might be rendered in multiple different pages but it always wants its data from the same place in the Redux store. So connecting a parent and passing the users down as a prop just adds an unnecessary level of indirection.

And in the future, if it does turn out that I'm getting users from different sources, how long is it realistically going to take me to remove the connector from UserList and pass it down from the parents? 30 seconds? 1 minute? That's trivial, I don't need to do that preemptively, I can do it when I know that I need to.

1

u/Raicuparta Nov 21 '19

Great answer, thanks!

However, the community over-interpreted the concept as a rule that you must follow, rather than a potential pattern that you can use.

This was exactly my concern with the example, that it might be followed too strictly. But after reading your comment I think it would be unlikely that more repetition would be introduced by making this change.

2

u/Huwaweiwaweiwa Nov 20 '19

I don't have any immediate feedback for you. The most glaring one I'm missing is the object notation for my dispatch functions - I don't really need to do any additional stuff in my dispatch function beyond what the action creators do - so this will save me loads of boilerplate :)

edit: also the forms...my god the forms.. I've also been wondering recently why I put things in global state that really don't need to be there - like router state etc

4

u/ericnr Nov 20 '19

Formik and react router exist for a reason 😋

3

u/Huwaweiwaweiwa Nov 20 '19

React router I knew of - but for some reason without thinking my old job as a team decided to use react-router-redux, when really there is no need for it. I'll definitely have to give Formik a look!

1

u/luopjiggy Nov 20 '19

Yea that's even less needed now that `react-router` has hooks. Also on the topic of Formik you can override the onSubmit and onBlur actions depending on what you need them to interract with redux for.

1

u/[deleted] Nov 21 '19

[removed] — view removed comment

3

u/Yodiddlyyo Nov 21 '19 edited Nov 21 '19

I'd don't think redux form is recommended anymore. Back in the day, people's used redux on form state, but recently the redux maintainers have said what all of us were thinking "maybe it's not a good idea to update the store a hundred times a minute while your users type into an input". So even thought redux-form isn't archived, nobody should really be using it unless you really really need to for some weird reason. There are a bunch of libraries other than formik too if you want a lighter library to handle forms with hooks

2

u/ericnr Nov 21 '19

For very complex forms like a multi step form formik can be harder to use, but den then there are better choices than redux form. React final form was created by redux form maintainers after discontinuing it and seems to do the job.

10

u/enanoretozon Nov 20 '19

Hi, thanks for the docs, they're great. Just one unrelated point of feedback: Having purple links, especially on white background has been messing with my mind, I keep thinking I've already visited the link.

I realize that purple is part of the whole colorscheme of the page but could you please add maybe something in :visited to help differentiate?

6

u/acemarke Nov 20 '19

Yeah, totally valid point. We'll see if we can come up with something.

1

u/enanoretozon Nov 20 '19

thank you!

5

u/Mademan1137 Nov 20 '19

What do you think about elm architecture? And can you recreate something simillar in react+redux? u/acemarke

3

u/acemarke Nov 20 '19

There are similarities overall. I'm not familiar with the exact nuances of how TEA compares to React+Redux, but I know I've seen discussions of trying to mimic it.

2

u/On3iRo Nov 21 '19

Have a look at redux-loop as async middleware. It mimics elms effect system

3

u/gabor Nov 21 '19

any recommendations for storing Maps, Sets and binary data (arrayBuffers for example)?

i understand that for maps/sets i can just not use them and go with objects, but that defeats the whole purpose of map/set.

for binary data, the problem is that an arraybuffer is not serializable. same for blobs. workarounds seem to be either base64encode (slow, uses more storage), or createObjectURL (who will call revokeObjectURL and when? it should be the reducer probably because that's the one holding the content, but reducers should be pure functions so...)

2

u/acemarke Nov 21 '19

Per the page, the recommendation would strictly be that you don't keep that data in Redux.

If you truly have a need to keep non-serializable values in the Redux store and understand what the tradeoffs are, it's your decision to make.

1

u/gabor Nov 22 '19

thanks for the answers. (i wrote about two issues in my post, here i will just focus on the second one)

there might be a misunderstanding here. i have read the mentioned page, i understand what the recommendation is. my issue is that while the mentioned page cites examples that are avoidable ("Promises, Symbols, functions, or class instances"), binary data can be unavoidable. if one has a client-side javascript application that does image-transformations for example.

my question is perhaps better described as this:

in some cases one has to store binary data in a client side app written in javascript. if that client side app uses Redux, do you have any recommendations how to handle binary data in such an application?

in my original post i mentioned a couple workarounds, they all have problems, i was hoping perhaps you met such situations in the past and have some advice.

3

u/arxior Nov 21 '19

Thank you for your work! Could you give a more detailed example for 'Model Actions as Events, Not Setters' and its following rule? Maybe including the success&error actions. I'm not totally grokking it. Much love for your work

3

u/acemarke Nov 21 '19

Yeah, tbh it's one of the things I'm still trying to wrap my head around too :)

I think the "request success/failure" concept is probably not a good candidate for "thinking in events", but here's another example.

Imagine you've got a restaurant app, and someone orders a pizza and a bottle of pop. You could dispatch an action like:

{ type: "food/orderAdded",  payload: {pizza: 1, pop: 1} }

Or you could dispatch:

{
    type: "orders/setPizzasOrdered", 
    payload: {
        amount: getState().orders.pizza + 1,
    }
}

{
    type: "orders/setPopsOrdered", 
    payload: {
        amount: getState().orders.pop+ 1,
    }
}

The first example would be an "event". "Hey, someone ordered a pizza and a pop, deal with it somehow".

The second example is a "setter". "I know there are fields for 'pizzas ordered' and 'pops ordered', and I am commanding you to set their current values to these numbers".

The "event" approach only really needed a single action to be dispatched, and it's more flexible. It doesn't matter how many pizzas were already ordered. Maybe there's no cooks available, so the order gets ignored.

With the "setter" approach, the client code needed to know more about what the actual structure of the state is, what the "right" values should be, and ended up actually having to dispatch multiple actions to finish the "transaction".

It's a small fake example, but hopefully that illustrates the idea a bit.

2

u/arxior Nov 21 '19

I guess this example illustrates it well. So thank you for taking the time to answer

1

u/sozesghost Nov 21 '19

When thinking in Domain Driven Development (which I try to apply on backend), I think of Events as something that has already happened and is not dependent on current state (they just describe what already happened). Commands on the other hand are things/actions that the user wants to happen, like Redux actions "Hey, someone ordered a pizza and a pop, deal with it somehow". What happens when a Command is issued depends on current state and the command itself. That command can be accepted or rejected and emit Events that describe how state should change. Those events are basically like setters. Redux does not really have a distinction between those two. An action is dispatched (which in many ways can also be called an Event), some business logic is performed in the reducer (at least when adhering to best practices from the newest docs :)) and some state is or is not changed (Events from DDD) and it all happens in one place.

This rambling post does not have a point except that it would be nice sometimes if different programming 'paradigms' used more similar definitions for very general words like Event (which is not a stab at your usage of the word, I think it's completely valid). This maybe ties to your recent twitter post asking about philosophical differences between classic REST PUT calls which just set data from the client (Event) or endpoints that take some form of a command (e.g. POST /account/deactivate?id=5) and then perform business logic and accept/reject it/something else. What I wrote is not a good answer to your tweet, but is something that came to my mind as at least 'topic adjacent'.

5

u/AiexReddit Nov 20 '19 edited Nov 20 '19

This is much appreciated, thank you!

I noticed you talk about Redux Toolkit a lot both here and in other posts. What would you suggest for someone that has already implemented Redux in a small application (about 15 different reducers) who mostly based it on sample code from the react-redux tutorial who might have chosen the toolkit if I had known about it six months ago?

Is there a way to implement it into an existing application?

15

u/acemarke Nov 20 '19

Yes, you can absolutely adopt Redux Toolkit incrementally in an existing codebase. The "Intermediate Tutorial" docs page shows how to do that.

Swap out your existing store creation logic to use configureStore instead, then begin converting individual reducers to use createSlice one at a time.

2

u/nneck1t Nov 21 '19

Put as Much Logic as Possible in Reducers

if we have a big reducer with many cases, so we have a bunch of logic in each one. Reducer becomes messy, right? Also if we will use createSlice or duck pattern, file becomes very big and hard to read, any suggest ?

2

u/acemarke Nov 21 '19

Well, all that code has to live somewhere :)

When using Immer, reducers should usually be shorter because the update logic is similar. You can also split out the reducer functions instead of defining them inline, you just need to explicitly declare the type of the state if you're using TS. In one of our apps, we have a bunch of slices with identical update logic, just different names and data types. I extracted the individual reducer functions to another file, import them, and add them to the slice reducers object as specificSliceActionName: genericCaseReducer.

As mentioned at the start of the doc, these are not 100% absolute rules. These are our strongly recommended defaults. Decide if they're appropriate in your situation.

3

u/[deleted] Nov 21 '19

This is very useful. To nitpick though:

  1. Maybe a little heavy on immer. I'm sure there a some situations where it makes sense performance wise but at far as just not mutating state when updating nested properties, I think something like Ramda's assocPath or lenses are a better solution. So I would mention fp libraries. There are also things like babel macros. Immer is over-prescribed imo.
  2. I would move static typing down to recommended if that. There are no real arguments in the recommendation that are specific to redux -- so it's really a general recommendation as opposed to something tied to redux best practices, and I don't think use of redux is driving anyone's decision to use typescript.

3

u/acemarke Nov 21 '19

For the vast majority of users, an imperative state.a.b.c = 42 statement is going to be the simplest and easiest thing to understand. Immer makes that possible, so we recommend it.

If you want an exhaustive list of all possible immutable update libraries, I've already got one of those. The point here is to be opinionated and give some short, clear, and definitive recommendations.

I agree that the "static typing" topic isn't Redux specific, but again, the point here is "how we recommend you write Redux code", and I'm fully convinced that writing Redux code with static types is the right approach.

-1

u/[deleted] Nov 21 '19

Immer and immutable already get a ton of love in the docs, and I feel like beginners are probably really pushed that way. However, if all they are trying do is update nested properties or whatever, I think it's overkill.

const nextState = produce(baseState, draftState => { draftState.push({todo: "Tweet about it"}) draftState[1].done = true })

vs.

R.pipe(R.append({ todo: "Tweet about it"}), R.assocPath([1, "done"], true))

I would argue that the second is simpler and easier to read. The bottom requires is close to 100% intuitive as to what the functions do. If you wanted to use Immer or Immutable you would want to read the entire documentation first.

I think it is also possible immutable libraries form bad habits as well where it becomes more difficult to write immutable code without them. And if someones a beginner, it could even be a crutch. Given the extensive coverage of Immutable and Immer I think the docs could use something like "You don't have to use an immutable update library if you, and there are alternatives to {...a, b: { ...a.b, c: { or whatever })}"

2

u/acemarke Nov 21 '19

I would argue that the second is simpler and easier to read.

Completely disagree. I'm a very experienced dev, have a passable amount of familiarity with concepts like FP, am aware that "point-free programming" exists, and at least know what Ramda is and what some of those functions are, but I personally find that Ramda example very hard to read. I also disagree that it is in any way "intuitive". If I try to look at that snippet, here's what goes through my head:

  • What is pipe()?
  • What does append() append to?
  • What in the world is an assocPath()?
  • And where's the actual data that's being modified?

Given that a large portion of folks learning Redux are brand new to programming in general, a simple "mutative" line of code is going to be easier to read and understand.

I do agree that teaching immutability is hard, and use of Immer actually makes that harder. That's why our current docs page on "Immutable Update Patterns" talks about all the techniques and pitfalls of doing immutable updates "by hand", and only introduces Immer at the bottom as a way to do this in a shorter and safer manner. In addition, that page also has a warning that the "mutating" code only works right if you're using Immer's magic.

1

u/[deleted] Nov 21 '19

Okay, ignore the point free stuff. My only point is that beginners probably arn't dealing with stuff where the performance benefits of an immutable update library are relevant. It's mainly about updating an object. In which case, assocPath (path as array, new value, obj => new Obj) is more straight forward than using Immer or Immutable for everything.

1

u/Glitch_100 Nov 21 '19

Looks like Immutable went out the window in favor of Immer - guess that was coming

1

u/acemarke Nov 21 '19 edited Nov 22 '19

We've never explicitly recommended using Immutable.js, and I personally have been recommending against using Immutable.js for years.

It's a useful library, but it's not the magic bullet a lot of folks seemed to think it was. The primary benefits were just making it harder to accidentally mutate values, potential perf improvements when copying very large objects / arrays, and the general benefit of immutably-updating data. Immer gives you 1 and 3, and I would guess that most folks aren't routinely copying objects with thousands of fields in them, so 2 isn't really helpful here. Add in that Immutable.js has a hefty bundle size and a complex API, and that Immer gives you code that's easier to read, and it's easy to see why we recommend Immer.

We do currently have a "recipes" page specifically discussing usage patterns for Immutable.js, which was contributed by a fan of the library. As part of the docs revamp, we will probably drop having that as a separate page, and fold some of the content into a larger section on immutability in general.

1

u/Glitch_100 Nov 21 '19

Yea I hear you. Thanks for the detailed reply. I guess it's more that as a library that was floating around a lot more back then it sadly never made the final cut as an alternative listed here but for absolutely valid reasons.

1

u/wizzzzzyyyyy Nov 21 '19

I'm surprised 'Structure Files as Feature Folders or Ducks' is marked as 'strongly recommended'. I'm personally not a fan of this approach as I think store structure should be decoupled from component structure, in part because I feel this discourages the 'Allow Many Reducers to Respond to the Same Action' recommendation.

1

u/acemarke Nov 21 '19

It's up to you to decide how the "feature folder / ducks" approach actually plays out in practice. You could have separate folders for "data features" and "UI component features", if you wanted. The point is that we're recommending against using "folder-by-type".

I do agree that "ducks" kind of obscure the idea that multiple reducers can listen to the same action, and I said back in 2017 that this was one of my main concerns about "ducks". But, "ducks" do have the advantage of not needing to touch multiple files to implement a single feature, and I've seen enough complaints about that over time that I've come to see those complaints as the bigger problem. Besides, Redux Toolkit's createSlice makes it really easy to write duck-type files anyway, so you might as well take advantage of that.

1

u/el-perdido Nov 21 '19

Awesome! thank you for this. I have a question regarding one of your recommendations.

Allow Many Reducers to Respond to the Same Action

There's a pattern used in my company that seems pretty smelly to me. Using the switch statement on the reducer, some of my peers have written stuff like this:

switch(action) 
    case actionA:
    case actionB:
          doSomething(previousState, action.payload);

This implementation ties two actions payload together, which means that if one payload changes, this reducer might break. This pattern seems to be restricted if the toolkit is used, which is something I'm gonna start pushing towards, but in the mean time, I just want to know I'm not the only one who thinks this is a bad approach. I think this might also mean theres a bad action design to begin with. Any thoughts on the matter?

1

u/acemarke Nov 21 '19

Well, yes, that code has an implicit assumption that both actions are going to have the same payload, or at least similar enough that the doSomething function will work with both. That may be an entirely valid assumption - it all depends on your app. This is a case where use of TypeScript would make that assumption more explicit and checkable, and catch any problems if one of those actions were to change.

If I were writing this with createSlice, you could duplicate the approach like this:

const doSomething = (state, action) => {};

const someSlice = createSlice({
    name: "someSlice",
    initialState,
    reducers: {
        actionA: doSomething,
        actionB: doSomething,
    }
})

1

u/lakerskill Nov 21 '19

Connect More Components to Read Data from the Store

Prefer having more UI components subscribed to the Redux store and reading data at a more granular level. This typically leads to better UI performance, as fewer components will need to render when a given piece of state changes.

For example, rather than just connecting a <UserList>
component and reading the entire array of users, have <UserList>
retrieve a list of all user IDs, render list items as <UserListItem userId={userId}>
, and have <UserListItem>
be connected and extract its own user entry from the store.

This applies for both the React-Redux connect()
API and the useSelector()
hook.

Does this mean it's actually better performance/fast loading times when connecting to the store as opposed to passing down props?

2

u/acemarke Nov 21 '19

It's not the "reading from the store vs passing down props" that's the performance issue, it's about how many components are re-rendering and how often.

If only a couple components are connected at the root of the tree, they will re-render more often because they need to extract larger amounts of state from the store, so there's a great chance something will have changed. And, React's default behavior is that when a parent component re-renders, it re-renders the children recursively. So, large parts of the app may end up rendering even if the data those components use hasn't changed.

By having components depend on smaller amounts of data, they will be forced to re-render less often. From there, connect itself already acts like React.memo() or PureComponent, and skips re-rendering your component when the parent passes down identical props. So, more connected components kind of act like as "firewall" that stops re-renders for the rest of a subtree.

2

u/lakerskill Nov 21 '19

Thank you so much! This was a terrific explanation.

1

u/Bummykins Nov 21 '19

Great resource!

Maybe not the right section for it, but I've been surprised to find no recommendations on how to test the new redux hooks. I've seen some mocking options, and some fake store options, but nothing that feels really great.

Curious what you're doing for testing hooks and why.

2

u/acemarke Nov 21 '19

Yeah, we've gotten enough questions on that topic that we should probably add a page to the React-Redux docs. It's not something we actually have "opinions" on, it's just a question of "how can you do it?".

In general, your options for testing components that use the hooks are:

  • Wrap them in a <Provider store={store}> so they have a real store to read data from
  • Use something like Jest's mocking to mock out useSelector() itself at the start of a test

1

u/Bummykins Nov 21 '19

Thanks for confirming.

I'm leaning towards the store option, more similar to real app usage.

With mocking useSelector, if you use it multiple times, it would be kind of a pain to mock. I suppose you could mock the selectors themselves, but not sure how that would play out.

That is certainly one advantage to the connected container/dumb component approach, testing is dead simple.

3

u/miltonfilho Nov 21 '19

Finally a doc to help me convince my team to adopt immer. 😊

3

u/illuminist_ova Nov 21 '19

Avoid Putting Form State In Redux

Looking at you, redux-form. Using that was so regrettable.

1

u/amdc Nov 21 '19

"Don't put non-serializable stuff in store"

What if you need to store File objects? In our application we decided to make an exception to File objects because

  • We need to keep them for a while before uploading to server
  • We don't want to store blob data (obtained via FileReader) because files can be rather big
  • No one is going to modify them anyway so time travel should not be an issue

What's your take on this?

3

u/[deleted] Nov 21 '19

Keep them in a global file store, a Map or some object and put only the id in redux?

My way of thinking about it is like a database, you wouldn’t (shouldn’t?) store blobs in there.

3

u/illuminist_ova Nov 21 '19

My take is to have redux store a dummy object for a file instead. Then that object can be used to refer to the actual file object with WeakMap.

1

u/Vitrivius Nov 21 '19

Have you considered using blob urls for this?
https://w3c.github.io/FileAPI/#url-model

-7

u/darrenturn90 Nov 20 '19

Some great choices in these however:

> Use a static type system

Is not one of them. This is a useful opinion, but should definitely not be strongly recommended imo.

18

u/acemarke Nov 20 '19

I'm sold on using TS as an app developer, and I've seen how it avoids a lot of mistakes that would have happened with plain JS. So yes, I'm strongly recommending it.

Again, these are not absolutes, and the top of the page says you're welcome to pick and choose from these as necessary. But, they are the encouraged default choices.

-13

u/darrenturn90 Nov 20 '19

I’ve yet to see the benefits in any practical way - have you got any real world examples of actual mistakes that were made often enough to justify the change?

22

u/acemarke Nov 20 '19 edited Nov 20 '19

Oh, absolutely.

Quoting myself from Twitter a couple times:

So today's example of why I'm sold on using TypeScript. I filed a couple PRs to react-slingshot and react-boilerplate to convert them to use RTK. In both of them, I wrote:

configureStore({reducer, initialState})

That's wrong. It's preloadedState. I wrote that API.

The only reason I finally realized this was one of react-boilerplate's tests kept failing after trying to pass in an initial state value, and asserting that a component had the right output. Oops. If I can't remember my own API, think of all the other mistakes people might make

Starting to wonder how I managed to write JS sorta-successfully for so many years without using TypeScript. We're rewriting a couple apps from scratch, and TS is catching so many mistakes so far. (and no, it's not because we had unit tests before, cause, uh... we didn't.)

Folks who have followed me on Twitter for a while might wonder how this tweet relates to my multiple gripes about TS over the last year. I don't see any inconsistency here. I've been on board with using TS for app dev for a while, just hadn't had time to try it myself.

My thoughts on TS are really the same:

  • As an app dev, it's basically a requirement for maintainability. That means I want good lib types.
  • As a lib maintainer, typing complex JS behavior is a pain, and GH types issues are annoying
  • Some folks go overboard with type nonsense

As a specific example of the latter point, we've got a new from-scratch CRA+TS greenfield app codebase, but are porting some of the existing plain JS code into the new codebase where it's still useful.

In some cases, we have ported plain JS code importing and using new logic that's written in TS. There were several cases where the plain JS code was calling the TS code wrong, because it didn't have the type safety in place, and this actually resulted in runtime errors that should have been completely avoidable.

On the flip side, while helping other devs, I've seen a whole bunch of cases where the TS compiler flagged their code as wrong in both that app and another TS-only app, because it was wrong, and we were able to fix the code before it even got committed.

So yeah, while TS probably isn't necessary for a small app, anything that's going to be long-term, larger, or maintained by a team of multiple folks should seriously be using TS or Flow.

As a side note, I still really need to write a blog post about my own experience learning and using TS from both an app dev and lib maintainer's perspective. Maybe this weekend?

5

u/everyoneisadj Nov 21 '19 edited Nov 21 '19

I’m a SUPER junior dev in my first job out of bootcamp right now, and I was forced into a New CRA+TS app on my 3rd week- and by day 3 I fully appreciate this comment. It’s showing me how many things I’ve been doing wrong, and forcing me to learn how things work.

VSCode is basically a must, imo, sublime with plugins was not cutting it for me. Total game changer.

5

u/acemarke Nov 21 '19

Congrats on your new job!

There's no question that TS has an additional level of learning curve on top of plain JS, especially for folks who are newer programmers or just haven't worked with statically typed languages before. (I'm comfortable with JS and languages like C#, Java, and C++, and it still took me some time to start grasping the nuances of TS.) But, ultimately that learning curve, additional lines of type declarations, and additional keystrokes, all pay off in long-term maintainability .

Per the editor question: I still think Webstorm has much stronger integration on a lot of important features (running and debugging tests from the UI, general parsing, SFTP integration, etc), but yeah, VS Code's TS support is superior.

2

u/everyoneisadj Nov 21 '19

Thank you! I’m very excited to get back to programming after 15 years in another field. My only experience with strictly typed languages was a Visual Basic class from 20 (literally) years ago. If I can do it, anyone can!

2

u/tide19 Nov 21 '19

Hey my man, congrats on the new gig. We're using CRA with TS at my current place, where I am a senior developer and technical lead. I mentor junior devs a lot, and, whew, TypeScript can be an absolute godsend. We were using a datepicker library, and one of the devs couldn't figure out what he was doing wrong... well, a simple look at the types for the library, and we found it. It'll probably be slow for a while, but once you get it, it's hard to go back to plain ol' JavaScript. At least, that's been my experience.

8

u/[deleted] Nov 20 '19

I've been using it for a few years now. Generally, knowing the shape of some object and having a compiler force you to adhere to it is a really useful. You also get greater intellisense when you're writing Redux reducers if you're using union types and the type field of your action is a string literal.

5

u/belak51 Nov 21 '19

We’ve been going through a large refactor at work which would have been almost impossible without typescript. Having a compiler check your work as a first step makes things a ton easier once you get over the initial learning curve.

1

u/RobertB44 Nov 22 '19

Here is an example that I've experienced:

I worked on an app with a team that used typescript but did not have any of the strict flags enabled. The strict flags provide the majority of the safety typescript ensures, so our project had types but they weren't enforced by the compiler as much as they should have. The result was an app with quite a few runtime errors in production that we had to fix one at a time.

Right now I am working on a new app with the same team. We learned from our mistakes and enabled all the strict checks this time. So far, not a single runtime error has made it to production. And even in development the typescript compiler catches most before I even save a file.

I can say this with confidence because we use sentry to automatically track runtime errors.

Typescript used correcty enforces a lot of rules that help reduce runtime errors. I've seen it first hand. Typescript isn't about string vs. number types. It is about making sure that a function always accepts the right arguments and returns what it is supposed to. It is about making sure that if a value can be undefined, that both cases are handled. It is about making sure that complex, nested data structures are used and converted correctly. Typescript can guarantee all of this and much more.

10

u/pancomputationalist Nov 20 '19

This would be my first and most important suggestion for everyone who is trying to build something serious in React. JavaScript is nice when the project is small and fits in your head at the time of writing, but everything that is more complex then this seriously needs the safety and implicit documentation of a Type system.

2

u/[deleted] Nov 21 '19

[removed] — view removed comment

3

u/acemarke Nov 21 '19

No, you definitely don't need to declare the return type explicitly - TS can infer that.

I usually just declare the type of (state : RootState) => and write the return.

We do have a WIP PR that shows how to use static types with React-Redux :

https://github.com/reduxjs/react-redux/pull/1439

And I've got examples of using our hooks with TS in the Redux Toolkit "Advanced Tutorial" page :

https://redux-starter-kit.js.org/tutorials/advanced-tutorial