
Learning Node.js and React while building a product - senoff
https://javascriptkicks.com/articles/147418/ramp-receipts-learning-node-js-and-react-while-building-a-product
======
acemarke
Hmm. So, the complaints about React are "no convention over configuration",
"we didn't like JSX", "event handlers require binding for `this`", and
"trouble finding a correct source of truth" for articles and such.

The first two are pretty common. Some people _love_ that React lets you pick
and choose the other pieces that you need for your own application, while
others hate that React isn't a kitchen-sink-provided framework like Angular.
(Relevant HN comment from a while back on "frameworks vs libs":
[https://news.ycombinator.com/item?id=10969819](https://news.ycombinator.com/item?id=10969819)
). Ditto with JSX - some people love that it's almost exactly the same syntax
as HTML, while others hate the idea of having anything HTML-like in their
components or dislike that it does have a few minor differences from actual
HTML syntax.

The event handler complaint I find a bit more odd. Admittedly, I never got too
deep into "vanilla JS" or jQuery, so I haven't spent too much time writing
non-React event handlers, but having to bind methods is very much an artifact
of how `this` works in Javascript (especially with classes) and not specific
to React.

As for a "correct source of truth", well, I have that covered :) I keep a big
list of links to high-quality tutorials and articles on React, Redux, and
related topics, at [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics.

~~~
miroslavpopovic
Hey @acemarke, thanks for the comment!

For myself, I still have not decided whether I like JSX or not :) My colleague
finds it great, and I like the declarative nature of it, just need to persuade
myself to accept it mixed in JS file.

Yes on .bind, but I got used to not having to care about it in Aurelia (and
Angular also). Got my fair share of `this` handling in pre-ES6.

And of course, thank you for the links. Bookmarked! :)

~~~
antihero
I've found that the best way to make event handlers is instead of doing

    
    
         class Blah {
            private handleThing(...) {}
         }
    

to instead do this

    
    
        class Blah {
            private handlething = (...) => {}
        }
    
    

this means that it is created only once, at instantiation of the component, so
it is fast, looks decent, and has access to `this` as it's technically a
method on the object, not the class.

Also, if you're coming from C# land, head straight to TypeScript 2.3 - it's
lush and handles the latest ECMAScript stuff wonderfully, and you get static
type checking, interfaces, union types, etcetera. The only issue is when a
package has no type definitions or no supplementary @types package, which
sucks but they exist for most popular packages. Also VS Code is built with it
in mind and brilliant to work with.

As for stacks, I'm currently really enjoying redux/redux-observable and my
helper lib redux-rx-http (for API), I find harnessing the power of RxJS to
manage side-effects through "epics" is a really elegant and decoupled way to
chain a bunch of things that you want happen together.

~~~
jbrantly
One problem with using fat arrow syntax like this is the method is no longer
attached to the prototype so it's not shared across all instances and is less
memory efficient. It also doesn't work well with React HMR if you're using
that. If you can use decorators I highly recommend autobind-decorator:
[https://github.com/andreypopp/autobind-
decorator](https://github.com/andreypopp/autobind-decorator)

Also I think you're using a TypeScript-specific `private` syntax there which
likely changes the runtime semantics so my comment really only applies if you
don't use that.

------
baron816
You don't have to use 'this' at all in React. I've written about it here:
[https://medium.com/@baronmaximilianwilleford/react-
without-t...](https://medium.com/@baronmaximilianwilleford/react-without-
this-39a76b8f2160)

I never use 'this', 'bind', 'apply', 'call', 'class', and only use 'new' to
create React components. I find it much easier and more fun to work with React
as a result. I hope other people would give it a try.

~~~
kaonashi
bind is useful as a curry that's built-in, but I always pass `null` as the
first argument.

not a huge fan of the `new` keyword in js; it's difficult to mock and there
are better options (Object.create/freeze e.g.)

------
caleblloyd
If your team is from a .NET background, you may be better off using something
with first class Typescript support.

I have been working on a boilerplate that uses VueJS with typescript. It is
still reactive. I setup the UI to closely mirror the structure of a .NET MVC
app. It is much more intuitive to me coming from a strongly typed OO
background.

The boilerplate is not fully done yet, but here is the UI portion if you'd
like to browse the structure: [https://github.com/caleblloyd/dotnet-core-
boilerplate/tree/d...](https://github.com/caleblloyd/dotnet-core-
boilerplate/tree/develop/ui/src)

~~~
tracker1
There are a lot of people using Typescript with React... it's not so bad, I
don't see the point nearly as much as some, but it's definitely there, and
pretty well supported.

~~~
caleblloyd
I tried typescript with react, but found that I was constantly adding `: any`
when dealing with `props` and `dispatch`. It felt like it was getting in the
way more than it was helping.

~~~
tracker1
You could specify them though, or not do `: any` which iirc is implicit?

------
pdog
Link to product: [https://rampreceipts.com](https://rampreceipts.com)

------
dcgudeman
Pretty interesting read. I have had pretty much the same experience with
documentation around react, and although Angular 2/4 documentation can be
confusing at times at least you know what you are reading isn't outdated. Also
as far as their backend choices I'd like to know why they went with knex over
sequelize.

~~~
miroslavpopovic
Thanks! I guess we just run into knex first, found out it works nicely in our
app and continued to use it.

------
WithHighProb
Not super related, we find the type check lib rho-contracts useful
[https://github.com/sefaira/rho-contracts.js](https://github.com/sefaira/rho-
contracts.js).

