[QUESTION] ReactRedux Questions #1357

New Issue

fergalmoran · 2025-08-09T17:19:50Z

fergalmoran commented

2025-08-09 17:19:50 +00:00

Originally created by @antmdvs on 9/28/2016

@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:

An enhanced developer experience (uni-directional data flow is "easier to reason about")
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

*Originally created by @antmdvs on 9/28/2016* @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

fergalmoran closed this issue

2025-08-09 17:19:50 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#1357