6 ms·
Learning Node.js and React while building a product
- pdog 9y agoLink to product: https://rampreceipts.com https://rampreceipts.com
- acemarke 9y agoHmm. 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.
- ben_jones 9y agoReact is a tool like any other. If someone argues for or against the use of React based on anything other then the actual design / API / implementation / results of the framework its just a bad argument.
- miroslavpopovic 9y agoWell, this is just my (and partially of my colleague) subjective opinion after spending a month working with it. Of course, that's due to change once I get enough mileage with it.
- miroslavpopovic 9y agoHey @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! :)
- jmschlmrs 9y agoAre you using arrow functions? I find that using es2015 arrow functions for class methods takes care of most of the problems around this and react. The only annoyance is dealing with binding event handlers to items/components in a list. Generally you need to abstract the list item into it's own component and do the event handler binding there. I don't use .bind() anywhere in my react code.
- miroslavpopovic 9y agoYep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers. In fact, I believe class property syntax helps with that, but we only figured it out after we built these few pages and components necessary for the web app part.
- coldtea 9y ago>Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers. They do. Just do: myHandler = (v) => { ... } and you don't need to bind in the constructor anymore. You'll need to use Babel of course to transpile that.
- miroslavpopovic 9y agoYes, class properties syntax. I mentioned that in the article.
- abritinthebay 9y agoAgreed. The main complaint is just "I want a framework and I chose a library." JSX isn't even required either. It just desugars into: React.createElement(elementClassorString, props, children); If they want to use their own function for that... they can, but JSX is a trivially easy way to describe nested components (which can get verbose with the above). A nice bonus of JSX is that it also means your components and render templates are not tied to React at all (if you're using stateless functions anyhow). You can switch the React.Component part trivially with babel to anything else (like deku, yolk, a custom one, whatever). So.. yeah, seems an odd complaint.
- godot 9y agoI find it a bit odd that both you and the parent commenter (acemarke) seemed to have interpreted the post in a completely different tone than I did. I didn't find anything in the original blog post in the tone of a "complaint". If anything, they were merely pointing out what kind of things they run into and their thoughts, while transitioning from an ASP.NET background. It's actually a really helpful read if you also happen to come from ASP.NET and are looking to pick up the Node/React stack. I personally also came from a different stack only recently (not ASP.NET) and dove into Node/React a few months ago, and found the way he expressed his views helpful for myself to align my thoughts.
- acemarke 9y agoYeah, re-reading it, the tone was a bit more "things we ran into" then "stuff we hated". That said, the items listed are definitely common complaints or points of argument about React that I've seen numerous times, so I was coming at it from more of that reaction.
- miroslavpopovic 9y ago> I didn't find anything in the original blog post in the tone of a "complaint". If anything, they were merely pointing out what kind of things they run into and their thoughts, while transitioning from an ASP.NET background. Yes, exactly this! There's nothing to hate really. It's more of a complaint against our inability to quickly grasp new concepts than trying to throw some stones over to React.
- WithHighProb 9y agoNot 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.
- caleblloyd 9y agoIf 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/develop/ui/src https://github.com/caleblloyd/dotnet-core-boilerplate/tree/d...
- tracker1 9y agoThere 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 9y agoI 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 9y agoYou could specify them though, or not do `: any` which iirc is implicit?
- miroslavpopovic 9y agoWe also have a strong JavaScript background. Preferring JavaScript instead of TypeScript. Cool, nice idea for the project!
- deleted 9y ago[deleted]
- baron816 9y agoYou don't have to use 'this' at all in React. I've written about it here: https://medium.com/@baronmaximilianwilleford/react-without-this-39a76b8f2160 https://medium.com/@baronmaximilianwilleford/react-without-t... 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.
- dcgudeman 9y agoPretty 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 9y agoThanks! I guess we just run into knex first, found out it works nicely in our app and continued to use it.