[QUESTION] ReactRedux Questions

[antmdvs]

@SteveSandersonMS @DamianEdwards @jongalloway

Dear Steve et al.,

I've been watching this repo for a while, with a focus on the ReactRedux template. My .NET team is planning to convert a large mission-critical Silverlight app with a complex UI supporting many user interactions. That said, I felt React+Redux would afford us:

1. An enhanced developer experience (uni-directional data flow is "easier to reason about")
2. A better debugging experience (thanks to Redux's single store and time traveling)

Here's where I need clarification:

BUSINESS LOGIC

What lives server-side vs. client-side? Is the idea for this template to keep business logic in server-side .NET models and only run data fetching through the Redux flow, (calling the API to invoke any non-trivial business logic)?

GETTING THE MOST OUT OF REDUX

The more I learn about Redux, the more I learn how it contrasts with OOP. Business logic lives in FUNCTIONS (or sagas, epics...), not classes. See (https://medium.com/@jeffbski/where-do-i-put-my-business-logic-in-a-react-redux-application-9253ef91ce1#.v8onhcyjn)

If we only have reducers that slice up the API responses and update the state (I've seen the term "dumb reducers" somewhere but not sure if that applies here), I'm concerned we may be depriving ourselves of some of the "easier to reason about" goodness. (IOW, not using Redux to its fullest extent.)

If we're to build out more logic using Redux constructs to really reap its benefits, then I'm not sure what the value prop of a .NET backend would be..? We certainly don't want to write our business logic twice, much less once in OOP and then again in a functional approach.

Any input would be greatly appreciated!

Thanks,
Tony

[SteveSandersonMS]

Is the idea for this template to keep business logic in server-side .NET models and only run data fetching through the Redux flow, (calling the API to invoke any non-trivial business logic)?

It's up to you to select what you think will work best for you, but your outline here sounds like what most people are doing. As a basic principle, client-side code cannot be trusted, so anything that needs to be enforced (whether that's security, like who can see/edit what, or just that business processes are carried out in the correct sequence) needs to be server-side, with the client-side code just being a user-interface, albeit for rich and sophisticated UI it might be the significant majority of your overall codebase.

GETTING THE MOST OUT OF REDUX

As for the exact balance of OO and functional patterns that work best with Redux, I'll have to defer to the Redux community, as my experience with it is limited. Sorry!

If we're to build out more logic using Redux constructs to really reap its benefits, then I'm not sure what the value prop of a .NET backend would be..? We certainly don't want to write our business logic twice

As per above, your business logic will typically be split between backend and UI (e.g., based on how much it needs to be enforced, or whether it's really logic about a particular UI rather than the underlying business), so there isn't usually a huge amount of duplication. I'd say that whether you choose .NET for your backend or something else is just a matter of what your team feels is best for them writing that kind of backend storing/querying/processing code, which usually looks and feels completely different from UI code.

[MarkPieszak]

Agree with Steve completely.

@antmdvs
As he was saying, besides having some "dumb" session in your client-side application, you want everything else (important / business-oriented / true session) to be on the Server-side. How you set all that up is completely up to you.

We have a REST API setup (using WebAPI) to handle everything in our application, as well Websockets for some live-streaming updates to & from the client (this is also where I'm constantly saving the true session to Redis / etc.

We use Angular2 with Redux (NgRx) here, but the same concept you're going for.

I like to think about Redux as switch statements that manipulate the one source of truth (state) in your app. So let's say you have a Products reducer, with get / update / delete actions right? Well each one simply gets "dispatched" by events on the UI, which then goes to your Rest API, completes its action, and then updates your overall Application State. It really is a beautiful thing :) But yes, basically you ideally want "dumb reducers", unless the logic they are doing is.. moving something around, or changing the formatting, or manipulating data around before eventually sending it to your server-side api, etc.

There's a lot to think about with all this, but it's a great architecture to have. We've all gone through life with jQuery and prior without a single application state, it's painful ;)