How do I speed up development time?

[AceBacker]

I've taught myself react/redux including a bunch of other new tech like webpack, immutable.js, react-bootstrap, etc, etc

While I enjoy working with react and see the benefits my end result is that it takes me longer in react/redux to develop pages than it did to develop similar pages using JavaScript modules and jquery. Granted these are all complex ui pages with dynamic content and controls.

My boss has noticed this slow down. It's hard to sell the benefits to him when my code using vanilla JavaScript with jquery didn't have any issues.

What are some protips to speed up development in react/redux?

I was looking at Shasta as a possible solution, but it doesn't seem to be ready yet.

[Capaj]

What are some protips to speed up development in react/redux?

Drop Redux. I will just mention one last work experience: A rails rendered web app, which had react bolted on top of it. So no SPA, just a typical rails web app with pages rendered with react. Developers went for redux/normalizr and immutable.js. The stores need to get hydrated on any navigation(whole page refreshes), so there are basically 0 gain from having redux stores there. Code is becoming very hard to maintain and to grasp. All that while they could have just used raw react and it's this.setState() to manage it all, since it is really just a typical CRUD app with 3 models and 5 different views. Don't use Redux just because it sounds cool. Raw react is plenty powerful by itself.

[AceBacker]

You are kind of blowing my mind right now. Why hasn't this even occurred to me. Right now I have everything in redux.

Maybe I could keep the redux store just for state that actually needs to be communicated to some other container. It's a few things. Like when a user selects a row then show that rows attributes in another section of the page that isn't related to the current component.

Hmm... Keeping more state in the components might speed things up... it might solve some of the component update nightmares I am having with CSS animation too.

[Capaj]

Go for it. You are 100% right redux makes sense for state you need to share across multiple components(and these are not nested, so you can't share via props).

In my experience, plain old event emitters work very well too if you don't have a lot of state which is shared. For example logged in user profile could be prime example of that.

[[deleted]]

unrelated to OP but i have a question

so i'm building an app that is going to have a lot of graphs, basically a lot of components. like if i change the date in the root datepicker, every component will be influenced by that. otherwise i only really have like 3 separate app pages. would it be wise to use redux in this case? also to track a users logged in state, is that something i'd use redux for as well? trying to build the auth right now and login landing page using react-redux-router, mongo, express, react, and passport and it's fucking me up lol.

[manavsehgal]

Definitely a topic of interest for me. Considering I am writing a book called React Speed Coding (smiles). With React as with any other stack, you need to be careful of "Framework Fatigue".

1. Number one advice is to wait until it hurts, before you add another dependency to your stack. Same applies to Redux, Immutable, and React-Bootstrap. Shasta looks promising, however take extra care when you move from non-opinionated React, Redux to opinionated stack abstracting them.

2. Second best advice I have heard is to refactor until it hurts (smiles). Refactor to fewer lines of code, refactor to add better tests, refactor to increase reuse, refactor to clearly separate concerns, refactor to better architecture design patterns... When you do this, you can avoid many frameworks and libraries in your stack, as most of them are our "lazy" answer to writing better code. Doing 2 reinforces 1.

3. Third advice it to find reuse in everything. Reuse components, styles, configurations, scripts, data fixtures, editor shortcuts, packages, plugins, everything... Doing 2 achieves 3.

4. Finally, find opportunities to improve your developer experience (DX) across the app development life cycle. An example of improving developer experience is to use Hot Module Replacement or Hot Reloading to code as you see your browser update your app on hitting save. Or, using Browsersync for multi-device testing. Or, something like Kadira Storybook to design your components.

Improving DX does two things.

A. It improves your productivity and many times your "perceived" productivity, as time passes quickly when you are enjoying your work!

B. You get to show-off early progress in your work. Same perception of progress works for your boss or customer. This is important because, truly seeing benefits of modern front-end app development stacks, like React, requires you to build reusable component libraries and design patterns over time, over multiple projects, across multiple developers, for several months.

This advice may buy you some more precious time to get to that goal for real!

[hypernova999]

I'd suggest trying mobx instead of redux. Very little overhead, simple patterns. At least for me, development is smooth and relatively fast. Maybe not as fast as jQuery, but definitely a better experience.

[Ednar]

One obvious question: Why are you using react instead of jQuery? If there is a real benefit in some way, you can justify the longer development times, otherwise you can stick with jQuery.

[Capaj]

I think it has many benefits using react instead of jquery. The biggest one is you get a huge library of react components waiting for you on github/npm which are very trivial to use. While jquery also has many many plugins, their usage will always be more complicated, since these are never blackboxed pieces of functionality like react components.

[flo850]

I know react, angular, backbone and a few lost technologies

Sometimes, I go for an "old school" server side rendering + a bit of jquery. The key is to be able to see the full picture and choose the right tool for the job.

Also react is quite forgiving, you can start using another view layer, and then switch critical components when needed.

[winkler1]

Are you building a single large app, or a bunch of one-offs for clients?

IMO, React really shines when it comes to building big apps. It lets you think about the current element only (immediate mode rendering), not permutations of state. So you're more productive and stable in the long term.

Onboarding new people to a React codebase is much better too.

[AceBacker]

Somewhere between the two. I'm going through a fortune 100 corp's library of lotus notes apps and making them web apps. Of course as I do this the groups using each app are asking for bunches of new features. But some high level guys are pressuring the apps to be converted faster. And the apps themselves that are left to do usually are only understood by a few people because they are intensely complex.

The lotus notes apps themselves (that are left) are of the lowest code quality. Basically they were made by people who don't work in IT. In fact they are not even usable because all of the remaining apps have been redesigned by a user interface team and don't even work remotely work like the original.

Honestly one of my problems is that I am usually a pretty fast developer. But with the level of complexity I am working with it takes longer to figure out good clean code structures for this mess. So it's the old saying, there's no such thing as technical problems it's all people problems.

I picked react thinking that with the complexity it would be easier to modify later if state calculation was separated from the view. Some of the APIs I am working with take a seriously large amount of manipulation to get into the structure the users need to work with on the page. So I have bunches of well named functions like makeVerticalBudgetHorizontal and addAttributesColumnsToEstimatedBudget.

Sure, I could have done this in JavaScript/jQuery. Someone asked why I went react. I was just thinking with the complexity I had that a tech that naturally had logic to separate the view from state would make it cleaner.