> React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actually only the view layer, and makes it significantly easier to write your business logic using plain old JavaScript functions/classes.

This. This is spot-on IMHO.

You can literally use React for JUST the view layer... you don't have to maintain any state inside react if you don't want to. Early on, many did use it for just a view layer.

> in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else.

I'm not an expert by any means, but I wrote a fairly substantial react app recently, and I found that redux not only made this straightforward, but made it hard to do anything else. I did have to learn redux and redux- saga on top of react, but it wasn't hard.

Just a FUCK-TON of boilerplate :P

You say boilerplate, I say simple declarative layout of the boundaries between UI, state and state transitions. :-)

People use the word "boilerplate" a lot, but everyone seems to have something different in mind when they say it. What specific concerns do _you_ have? I'm a Redux maintainer, and I'm always happy to try to help offer possible solutions.

I don’t really think there is a way around it if you go with the action/reducer/saga model.

I enjoy my code fairly explicit, so writing a button click that invokes some request has me writing:

- A click handler

- 3 new action name consts (request, success, failure)

- An action instantiation function that takes the necessary arguments for request.

- A saga function that catches these request actions, runs a request, and invokes the success action/failure action depending

- 3 handlers in my reducers. One for every action.

It all adds up if you have a ton of buttons :P

Sagas are a great power tool, but I personally wouldn't use them for most simple API requests, largely because of the need for "signal actions" to trigger the logic.

You might want to check out our new `redux-starter-kit` package [0], which can simplify some common use cases for things like action creators and reducers. There's also many other existing libraries to handle repetitive code like API requests as well [1].

[0] https://github.com/reduxjs/redux-starter-kit

[1] https://github.com/markerikson/redux-ecosystem-links/blob/ma... , https://github.com/markerikson/redux-ecosystem-links/blob/ma...

I think you need to use sagas for either all your logic, or none of it. Having it half/half just means you’re always searching for where something is located.

That said, thanks for the recommendations! I’ll check them out.

FWIW, I use sagas _and_ thunks in my own app, depending on what it is I need to do.

Also related, the new Redux FAQ entry on choosing between async middlewares: https://redux.js.org/faq/actions#what-async-middleware-shoul...

This is exactly the thing we need fixed. I get that Angular has one way of doing it, but I still feel like it's going in the wrong direction (too Java-like).

I agree. I feel using JSX for example to define application routes (a la react-router) or do any other type of non view logic is just wrong.

Well, you usually have more than one layer of state... a holistic application state, and a control/component state.

It's possible to completely separate out your state machine and use it separately from rendering... It's also possible to integrate it all. Best practices are generally somewhere in between and having your state where needed... if it can be contained, contain it... if multiple controls need it, globalize/context it.

React was never a view-only library.

Pete Hunt always said he saw React components as mini MVC modules.

it's even less true nowadays with features like Context or suspense to supplement the component states. Redux was kind of a temporary hack.

I distinctly remember the phrase "V in MVC" being prominently displayed somewhere on the official React website(s).

Found it: https://web.archive.org/web/20140329114924/http://facebook.g...

> JUST THE UI

> Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.

So I was mistaken. It didn't say that's what it's only intended for, but that's what many people use it for.

Either way, it's not great at the M or C parts of MVC. Context does very little to ease that pain. Redux was more manageable but also overly complex, but it's only React's design that forced it to be so complex.

But managing state is quite hard in general. Angular proudly advertises it solves all problems you can have on the frontend but I would take react state + utils over angular's magic templates, rxjs and bindings any day.

Right, and that's what I'm recommending we in general try to innovate on: better state management than React, but with the ease of writing view components that React has showed works well. Since the view is hierarchical, it makes sense for components to inherently also be hierarchical, but business logic often doesn't match up to React's component hierarchy, so it should not be done inside React or tied to React's hierarchy.

Out of curiosity, have you actually tried the latest version of Angular to see if your preference does hold up? It’s come quite a way since the bad old days.

I can't speak for GP, but have used angular up through 4.x (not quite current) and don't find it better than React's ecosystem imho.

With React I can often bring in additional components and libraries without friction. With Angular it feels like doing anything means significant friction. And heaven help you if you want to change the way something internal works, or work around things.

I can’t say I’ve had that much trouble bringing in third party libraries, nor have I had a need to change how the framework works internally. I think this is the same as with most frameworks, you tend to just use them rather than doing stuff under the hood. Can you give an example?

At this point not really... it's been over a year since I've had to really worry about it. It was better using angular-redux or ngrx, but still was a weird experience. When you have eventing issues with RXJS, or handling integration with other libraries, it's definitely not as broad or mature as the React space is. Anything from chartjs to color pickers, I'm trying to recall the last big issue I had in an angular app. In the end, I just remember pain all along the way more than most specific examples.

Oh yeah... drag-drop integration... that was the single biggest pain. None of the component libraries worked well, and doing it manually was harder than I've experienced before, including just straight JS, and definitely worse as a whole than using say jQuery-UI.

If it were a year or more ago, I could cite better examples of pain points. 2+ is better than 1.x, but still horrible. I'd rather see people adopt Vue over Angular. I still prefer a react-alike over any of them.

Funny you should mention drag drop, it’s now built in as of version 7, just released a few days ago. Look up the CDK for more details.

Whenever I’ve needed drag and drop functionality in the past I’ve found it in existing UI components. A fairly comprehensive one is primeng. I’ve also added an angular colour picker and highcharts without very much trouble.

Often when I hear people complain about angular, I wonder if they just don’t understand it very well and are trying to do things the wrong way. Angular is opinionated, but I don’t find it terribly difficult or painful, though at this point I do have rather a lot of experience with it and find it’s difficult to put myself back in the shoes of someone with less.

I really do enjoy the framework and how comprehensive it is. I like having a framework that gives me so much out of the box without having to go to a somewhat unstable ecosystem of related projects. Frankly I think Angular’s bad name is due in part to it simply being fashionable to put Angular down, and partially because it’s critics never really learned how to use it.

Also, something about jsx just rubs me up the wrong way.

I feel the opposite... I feel like React, by comparison, and JSX are much like the huge lego sets you used to be able to get generically... being able to plug in whatever I want. Angular feels like being stuck with a Duplo version of MindWorks.

As to JSX, it's something close to what I wanted a long time ago... when E4X was added to Mozilla's browsers, along with support for it with Flash/ActionScript3 and XML literal support in VB.Net (not that I love that language) ... interactivity to the UI was SO much simpler. The shame is it was never really supported in other browsers, which left it dead on the vine.

When JSX came out, it's REALLY close to what I already wanted, and in most cases better. In the end, I can compose a React/JSX component starting with a static render function in a file by itself... I can grow it and turn it into a class or wrap it in higher order components. Compose with extensions like react-redux, material-ui, react-jss with ease. Every single time I write an Angular component, I'm looking up configuration arguments for @directives. It's just painfully restrictive by comparison.

Simplest react component

    // HelloComponent.js
    import React from 'react';
    export default ({name}) => <div>Hello {name}!</div>


    // StatefulComponent.js
    import Hello from './HelloComponent.js';
    ...
       return <Hello name={this.state.name} />

That's off the top of my head... that's just the code you have to write... Now, do the same thing in Angular off the top of your head, I'm willing to bet it's a LOT more verbose, ugly and hard to remember/modify what you need.