
Lessons learned as a React contractor - prostoalex
https://medium.com/@jolyon_russ/11-lessons-learned-as-a-react-contractor-f515cd0491cf
======
armandososa
OK. Here's what I've learn after ~2 years of doing react myself.

1\. Wrap third party components, so you can swap them easily if they become
unstable or you find something better. 2\. If you have a codebase that
predates create-react-app, take a look into its configuration, webpack is a
complex beast and they've figured many optimizations. 3\. Learn the concept of
High Order Components and use them to abstract common functionality (for
example, retrieving data from an API) 4\. Even if you use Redux (I do and I
love it), not everything belongs in there, use local state whenever it makes
sense first. 5\. Never, ever, depend on anything inside `react/lib`

~~~
JustSomeNobody
Re: #1, this is something non-web devs learned a long time ago. I wonder why
there's not more sharing of this type of best practice information. Everyone
stays in their own bubble, maybe?

~~~
ponyous
Even web devs learned this a long time ago. And no we are not staying in our
own bubble. As you probably know web is huge and it's hard to know all best
practices. Even in the language you are programming there are probably things
you don't know. People learn all the time, people start learning all the time.

It feels like people have superiority complex over front-end devs and lately
specifically javascript. It bothers me. What if you tell me your language of
choice and every time I see it mentioned somewhere I will post some random
"intellectual question" combined with stereotype that will make you feel
stupid and just demotivate you a bit. Maybe I am missing something but your
comment made me feel that way.

To answer your question fully; In my opinion it's because there is no single
entity that owns the web. No one controls which things should be deprecated or
continued, that's why it's happening much slower because big guys have to come
to an agreement. Apple provides best practices for iOS, Google for Android,...
MDN is a good resource but there is no official "BEST WEB PRACTICES" entity.

~~~
JustSomeNobody
I feel you took my comment too personal. Is wasn't an insult to anyone.

------
hoodoof
My lessons that I would add to this:

lessons 1: there's a good chance, depending on what you are doing, that you
_do not need_ Redux - avoid it if you can. much docunentation seems to imply
that it is a necessary hand in hand element of react development - not true. I
have never found any situation in which I need redux.

lesson 2:' use "create-react-app", and if humanly possible, don't eject from
it.

~~~
netghost
Is there any sane way to use Sass, Less, or PostCSS without ejecting though?
Not having variables available in your CSS seems pretty untenable for anything
that has more than a handful of styled components.

~~~
insin
You can use this fork of react-scripts which adds configuration for enabling
new options, including use of style preprocessors:

[https://github.com/kitze/create-react-app](https://github.com/kitze/create-
react-app)

~~~
hoodoof
The irony of forking create-react-app to add configuration.

------
kuon
About the "go without redux point", I've switched to MobX, and it helped me
greatly for this, as I can implement proper state handling very quickly even
when the project is in it's infancy. You just create a class, throw
@observable in it and boom, you get everything without any boiler code.

~~~
thomasrognon
I used redux for a year before switching to mobx (which I've now used for more
than a year). It is easier, faster, simpler, and scales better in my
experience. I can't recommend it enough.

~~~
sandGorgon
why did you do this ? we are already on redux.. but have been looking at redux
with some interest.

------
JTenerife
Here are my 2 cents:

1\. Don't use a boilerplate. Not even create-react-app. Learn webpack and npm
and TS / Babel. It's not that hard.

2\. If you havn't yet, take a second look at MobX. I got it once I realized
that I can organize my state just as I love it with Redux (normalized and
update strictly through actions). With MobX you don't need Reselect.

3\. Even though the React community seems to favor ES6, at least give
Typescript a serious try.

~~~
geewee
How did you get typescript working properly with redux? I never could figure
out how to get proper types in my reducers or HMR to work.

~~~
tomduncalf
You end up doing a bit of explicit casting in places to ensure type safety,
but it works. Little discussion I had about this with someone on Twitter which
may or may not be relevant:
[https://twitter.com/tomduncalf/status/804002710878044160](https://twitter.com/tomduncalf/status/804002710878044160)

I should write a blog post about Redux and Typescript - it would be good to
know which bits you are struggling with.

HMR works fine with Typescript, you do need to use Babel as well though. This
post I wrote should get you up and running:
[http://blog.tomduncalf.com/posts/setting-up-typescript-
and-r...](http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/),
it is a little outdated (1.9 vs 2.1) but I don't think any major changes
should be needed to make it work with newer versions. Unfortunately, HMR (v3
beta) doesn't play nice with react-router as far as I can tell, so I have
given up on it for now. I really miss it so I hope someone knowledgable finds
time to focus on getting it working better soon!

~~~
geewee
That's a really helpful blog post, actually. I thin the general pain points
are the same as in your twitter discussion - the reducers quickly start
feeling clunky with explicit casts or using two lines to export a constant for
the switch statement. It's obviously a possibility to just forego type-safety
in that part, but it'd be a shame.

Another general pain point (apart from the fact that a lot of the guides you
find seem reasonably outdated) is the general build setup. Your guide seems
really good, but generally setting up react redux and typescript is a bit of a
jungle.

If you do end up writing a post, please let me know!

------
sergiotapia
I shudder at the complixity of Redux. Ooh~ nice, you dispatch an action to a
reducer, ooh~. ~job security~

I don't know, it rubs me the wrong way when there are better tools out there.
Mobx, is much quicker to integrate and is easier to understand how to
integrate anywhere in a React app. Glad to see I'm not the only one who really
doesn't like Redux.

I mean check it out, it has an incredibly small API, and even smaller if you
use the right Webpack loaders.

    
    
        import { observable, observe, toJS } from 'mobx'
        export default class Store {
          @observable foo = []
        }
    

Then in your components just set or read from `this.context.store.foo`. Every
component using the same store will update it's reference to foo.

[https://sergiotapia.me/using-mobx-and-react-to-build-an-
inst...](https://sergiotapia.me/using-mobx-and-react-to-build-an-instant-
search-3eae1dd20cbd#.2d0j5dbqa)

~~~
Waterluvian
Redux is like 200 lines of code and very explicit without any magic. What
exactly is complex about it?

I think too often people don't appreciate that redux, like all frameworks is a
trade-off and is often the wrong tool for the job. Speaking about it as if
it's a generic framework to trade out for another framework is a sign that
it's being selected for the wrong reasons.

If it's not making your life easier, you probably shouldn't be using it for
that application. It's a really nice framing hammer, not a multitool ;)

When I got into front end, I used redux for a small SPA with about a dozen
actions and didn't really get it. "I could do this with react and basic
JavaScript. Why am I writing so much extra?" I refactored redux out and it was
much better.

I have another application that interfaces with a number of APIs, is a very
thick client and needs to recover from local storage on startup. Redux fit
like a glove!

~~~
cnp
I think a lot of the complexity comes from the incredible specificity of the
docs. The authors intend to _teach_, which while great (thank you) it can seem
overly complex for users who first land there.

I think a "Quick Start" section would solve a lot of the so-called
"complexity" issues, showcasing a few common use-cases:

\- Without React \- With React

Put bare-bones code under each of those sections and then let the user learn
the particulars as they come (and as their projects demand)

~~~
jaredsohn
Without Redux - With Redux

------
arbesfeld
I'm glad that the author mentioned sagas - this is one of the most underrated
parts of using Redux and it makes a huge difference in async code. To be able
to define complex asynchronous tasks as a series of "take", "call", and "put"
has significantly reduced the number of bugs in our async code.

Another point for Redux: it makes it much easier to understand bugs, both
locally and remotely with a tool like our LogRocket
([https://logrocket.com](https://logrocket.com))

~~~
jblok
LogRocket is truly fantastic.

------
blauditore
Some of these points are basically principles of (object-oriented) software
composition, just applied to react. Some examples:

\- "Multiple simple components are better than one highly customisable one" ->
Single responsibility principle [1]

\- "When all you have is two weeks, keep it lean" -> "Make It Work, Make It
Right, Make It Fast." [2]

\- "embrace the toughest linting rules your team can stand." -> Not really a
principle, but that's almost like simulating statically typed language with
compile-time errors and warnings.

[1]:
[https://en.wikipedia.org/wiki/Single_responsibility_principl...](https://en.wikipedia.org/wiki/Single_responsibility_principle)

[2]:
[http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast](http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast)

------
binocarlos
sagas are a steep learning curve and absolutely knowing what a generator
function is essential before opening the docs. They are a very productive tool
and worth the time imho.

They allow your redux containers to concentrate on selecting state and
triggering actions and the async stuff stays out of the way in 'workers'.

Defo worth a look if your redux project has more than a few pages.

~~~
cnp
Redux saga is so elegant it makes me want to cry - but you have to understand
generators first, as the author states. Once you get that part, then there's
really no going back. Much simpler (and far lighter) than redux-observable.

------
tzaman
> 4: Raw SVG >= D3 for simple data visualisations

You can have a bit of both. D3 has a dependency "d3-scale" [0], which is a
perfect choice if you'd like D3 to do the math and React to take care of the
DOM.

0:
[https://medium.com/@mbostock/introducing-d3-scale-61980c5154...](https://medium.com/@mbostock/introducing-d3-scale-61980c51545f#.3ohtn0oj9)

~~~
swah
Yesterday I wanted to find horizontally scrollable JS charts and had a hard
time.. any tips?

------
dx034
> My tip: test on lower spec machines

I wished ever developer would do that. Too many mobile apps or websites that
do very simple stuff (displaying content, simple forms) don't work properly on
older phones because of some sophisticated features that no one needs. Many
developers seem to think that everyone uses the newest machines and flagship
phones with high bandwidth, and forget about everyone else.

Unfortunately the fear of premature optimization is so big for some people
that their users have to suffer just because the programmer wanted to have a
nicer developer experience..

~~~
vinceguidry
The real reason people don't do it is because it's really hard to make a part
of your CI workflow. If the organization wants to dedicate resources to this,
great, but this isn't something the dev team is really equipped to do all by
themselves.

~~~
etimberg
It's definitely hard to do but tools like Selenium and Selendroid can make it
easier (assuming you have someone who has the time and energy to set it up).

Once you have system level tests running, then adding some phones or low-end
machines is relatively straightforward.

------
martijn_himself
Tangential question: does anyone have experience moving from full time (.NET)
development to freelance React / JavaScript development and is willing to
offer advice?

I'm currently employed as a senior .NET consultant and I am seriously
considering changing stacks and trying contracting / remote work in order to
have more freedom to travel and work from different geolocations amongst other
things.

Should I take some time off to learn React? Do I have to position myself as a
junior React developer?

~~~
bflesch
I think it is worth it. Once you get a grasp of React (and get a working
webpack setup, which was difficult in the past) allows you to build apps for
mobile (React native), desktop and web.

We're hiring react developers in Hamburg, Germany :)

~~~
martijn_himself
Great, thanks for the heads up! :)

Do you have any more information about your company, vacancies and hiring
process?

EDIT: a quick search has answered my question- no REMOTE positions I see :).
Hamburg is a nice city though!

~~~
bflesch
Oh we're just a small startup with a node.js / react platform hosted on AWS.
Due to our small size we have a simple and short hiring process, in which we
try to hire smart, experienced people.

As the sibling comment said we're also very open to remote working after a
certain period of getting to know each other.

I've refrained from adding the "REMOTE" keyword to our hiring posts because it
attracts a lot of remote (non-)"talent", and we're being swamped in mails from
people who don't fit the stated profile.

We've been burned hard by remote-only employees in the past because it is very
hard to keep the whole team on the same page, even more so with programmers
inbetween junior and senior who want a lot of autonomy but end up delivering
subpar results.

------
bayonetz
I find mockable end-to-end testing for React-based SPAs to be quite a mess. On
the one hand, "React is a just a view library" so e2e testing is orthogonal.
On the other hand, Redux/Flux + React pretty much get treated as the
counterpart to traditional MVC and the infrastructure upon which you build
your whole app on. But unlike Ember with it's QUnit e2e helpers or Protractor
for Angular, there is nothing like that for e2e testing a "React [+
Redux/Flux]" app. Unit testing with TestItils/Enzyme/Jest definitely doesn't
cut it. You can unit test all day but the isn't the same as integration and
acceptance-type testing. We had to basically roll our own using WebDriver.IO
and injecting a fetch-mock helper into our app to mock out the external API
calls. That last part is key when you need to test your complex SPA without
having to rely on backend API servers. Anbody else feel this pain?

~~~
Zalastax
You're completely right! It's unfortunate but the tooling for e2e tests isn't
"there" yet. For now the best alternative is Selenium (which I've had a lot of
trouble with getting stable) or
[https://github.com/DevExpress/testcafe](https://github.com/DevExpress/testcafe)

------
zem
what i've found over the course of my career is that the most invaluable
feature of boilerplate and scaffolding apps is to get a known-good build
pipeline up and running. a trick i've often found useful when migrating to a
new framework is to autogen a starter project and then start copying bits of
my existing project into it and getting them working. when i'm done, i usually
understand the new system well enough to go backport my changes to the
existing project (if i want to preseve git history) or simply start afresh
once all my tests are passing.

it is a sad commentary on the state of software development that the build
process is the most complicated and headache-inducing part of exploring a new
language or framework, but i've found that to be a constant across many
languages and many years.

~~~
forgottenacc57
Try create-react-app

------
dahart
> My tip: embrace the toughest linting rules your team can stand.

How good is the Flow type checker, vs ESLint or the Google closure compiler?

While I don't disagree with anything the author said, most of the time I feel
like ESLint is just a huge nag about white space. It's defaults have a bunch
of rules that in my opinion enforce style without improving code safety at
all, despite what the intro docs say. Someone I work with read some opinions
like this one and got the idea that ESLint represents correct JS standards,
and won't allow the white space rules to be relaxed. I'm stuck being forced to
put a space after my comment characters, and not being able to line up blocks
of repetitive code. It is admittedly nice to not have any white space style
arguments. OTOH, I never really had white space arguments before, and the
difference in both friendliness and code safety between using ESLint and the
Google closure compiler is huge.

------
forgottenacc57
For all the people who use redux - a question - how is redux better (for your
use case) than just a global variable?

~~~
acemarke
Lots of reasons:

\- Isolation of "write logic" means you know where to look to see what code is
updating a given chunk of state

\- Consistent state handling means it's a lot easier to think about what's
going on in the application

\- The DevTools show you a log of dispatched actions, and enable you to step
back and forth between states to see what the UI looked like at each point

\- Middleware lets you centralize app-wide logic, such as consistent
transformations for AJAX responses

\- Redux's constraints (such as wanting state to be serializable) enable a
number of other use cases, such as persisting state across page reloads and
synchronizing multiple stores remotely.

\- There's a rapidly growing ecosystem of addons and utilities for specific
use cases (see [https://github.com/markerikson/redux-ecosystem-
links](https://github.com/markerikson/redux-ecosystem-links) )

~~~
forgottenacc57
I've built a pretty large react app and never needed these things.

Things like stepping back through state seem honestly to me to be a gimmick
not worth the required investment of time and pain.

~~~
acemarke
I've seen a number of people make comments to that effect, and I genuinely
don't understand that point of view. I use time-travel debugging on a daily
basis, and it's a _huge_ time-saver for me.

I also don't understand the "required investment of time and pain" comment.
I've got a couple lines in my store configuration that sets up the Redux
DevTools extension, and after that, It Just Works (TM). In fact, one of the
posts in my "Practical Redux" tutorial series shows how to configure it:
[http://blog.isquaredsoftware.com/2016/11/practical-redux-
par...](http://blog.isquaredsoftware.com/2016/11/practical-redux-
part-3-project-planning-and-setup/) .

------
swah
Anyone working on Windows? Is web pack still the way to go? How does it
interact with something like phonegap? I have 3 similar projects and I'm super
confused which stack should I pick...

~~~
krlkv
webpack is still the way to go. Windows or not.

------
holografix
Given the amount of React knowledge in the thread and the fact that I just
finally groked Redux... what would you recommend to emulate something like
ionic? MaterialUI + some sort of flexboxing?

~~~
thomasrognon
For a material design look, I've used material-ui, mdl, and react-md. react-md
is the best in my opinion. Incredibly complete and polished for being done by
essentially one person. [https://github.com/mlaursen/react-
md](https://github.com/mlaursen/react-md)

------
chrislgrigg
This is great advice, particularly the part about small, similar components
instead of large, customizable ones. This is something I feel like I struggle
with in views much more than I ever did working backend, and it's healthy to
be reminded regularly.

On the subject of sagas, does anyone have a good solution for dealing with
`call` in TypeScript without losing type safety?

------
drum
Other things I'd add after building a React project:

1\. "Configuration over Convention" seems to be the mantra with build settings
and organization of the entire application. This can make adding features
slower if you're used to frameworks like Rails.

2\. SEO will require additional effort via server side rendering

------
ferdbold
"Linting also helps catch errors like reassigning consts and speeling errors"

Hehe.

------
wishinghand
Now I don't know what to believe:
[https://imgur.com/gallery/jL62c](https://imgur.com/gallery/jL62c)

~~~
cdelsolar
Don't use it. I used something called JS stack from scratch (it's a github
repo). You set it all up but along the way it teaches you everything. It
worked perfectly. The only JS I'd done before that was Backbone stuff and
requireJS.

~~~
zappo2938
I about to convert backbone views in a standing app to React components. Then
eventually convert the backbone app to React much later. Do you have any
advice, tutorials, and code repositories that would help me?

~~~
cdelsolar
The "Thinking in React" doc on the main React page, and their tutorial, were
greatly helpful, and it was about 80% of my reference docs. I didn't bother
with trying to interface with existing Backbone models, but your app may be
too huge to rewrite (it still took me several months to rewrite from scratch,
but it's a side project so it probably would have been a few weeks if full
time).

That "js stack from scratch" repo is also very helpful in setting up the whole
build.

------
griffinmichl
Definitely agree with #1. If there's one way I've changed as a programmer as
I've gotten more experienced, it's that I DGAF about repeating myself.

------
Sophistifunk
Don't rely on lint to catch speeling errors. It doesn't work on imports.
Flowtype or TSC (even without using any TypeScript syntax) are your friends.

------
huskyr
Excellent article! Lots of tips that are applicable to non-React projects as
well (simple over customisable components for example).

------
swah
Anyone working on Windows? Is web pack still the way to go? How does it
interact with something like phonegap?

------
linkmotif
And it's only been a year! <3\. Wild ride.

------
thght
> Happy 2016?

------
pmlnr
> January 2016, I changed my job title on LinkedIn to React developer

So whenever I start working on a new area, I should add that to my job title?

React Carpenter?

[http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...](http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac)

Also:

> 1: Multiple simple components are better than one highly customisable one

No shit. Ever heard of UNIX?

------
mstijak
I would recommend Cx to all React contractors. Cx runs on top of React and
solves many React/Redux pain points. It also offers comprehensive widget
library and charts.

[http://cx.codaxy.com/](http://cx.codaxy.com/)

Disclaimer: I'm the author.

~~~
Silhouette
This is a library that seems to do something a lot like what lots of other
libraries do, except this one costs hundreds of dollars per developer, comes
with only a year of support, and has many obvious problems with its licence
such as being revocable, being ambiguous about jurisdiction, and literally
having the word "DRAFT" stuck at the top of the first page.

~~~
mstijak
The licensing stuff is hard. I believe that our license is fair, even if it's
complicated.

You're right, many free projects offer the same or even greater functionality,
however, you're not taking into consideration time you spend to put everything
together. If your client is paying you hourly, Cx is an investment which pays
off quickly. We're contractors too and this was one of the reasons behind Cx.

I understand that commercial licenses are not very popular these days, but for
a small company like ours, I don't see any other model allowing us to
concentrate on support and the product in the long term.

~~~
Silhouette
I do understand that it's a tricky market to work in commercially. I have
nothing against charging for your work if it provides the value to justify it,
and similarly I have nothing against developers paying for tools that will
help them do a better job and/or save time. Your site didn't sell me on why
your particular product is better than what I could do with other tools, but
obviously that's a personal judgement and others might take a different view.

I also appreciate that writing a good licence is hard, but yours does seem to
be particularly awkward. For example, if we're developing a project for a
client, our terms typically state that they will have a certain minimum
standard of licence for any third party code we use, so they know they're in
the clear deploying or distributing whatever we build for them. Your terms
giving only a revocable licence would immediately disqualify your library, as
would any other hedging about being able to use it indefinitely once it was
paid for.

~~~
mstijak
The license is perpetual and can be terminated only if Licensee breaks the
agreement. I don't see how that can be an issue. Can you please explain the
problem?

~~~
Silhouette
The stated jurisdiction is unclear and the main licence term includes the word
"revocable". Unfortunately, that combination alone means the licence would
contradict our usual guarantees to clients. These typically say we will only
incorporate third party elements when the client has a perpetual and
irrevocable legal right to use and redistribute those elements as part of
whatever we're delivering. The furthest we've ever stretched this is including
FOSS with widely recognised licences where there may be a well understood
obligation on the client to provide the source code on demand, and some
clients won't be happy going that far.

The bottom line is that our clients don't want to get bogged down with the
terms of third party contracts or licence agreements and whether they could
undermine the whole project, so anything with the slightest hint of risk is
immediately more trouble than it's worth in this sort of area.

