You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Where do I put business logic in Redux is a question which still perplexes users. We do have an FAQ entry for it, but with no acceptable definition of what constitutes "Business Logic", it is hard to give concrete advice.
This issue is in response to this tweet . In here, we can collect some real world examples of client side logic and work down that list into what could be construed as business logic.
I am listing below the various kinds of logic I have seen/implemented in my career so far.
UI Visibility or behavior Use Case : Show/Hide some sections or fields based on the users roles, permissions. Notes: This can get complicated, with Attribute Based Access Control or other such complex requirements. I personally view it as a representation of UI state and handle it as such.
I usually come across two flavors of this, Application level UI state (for e.x. user is not allowed to edit anything, or view the comments section) or Component/Screen based state (for e.x. user is not allowed to change some field, if the domain object is in state "submitted") .
Use Case : Change the sections to follow based on the data. Notes : In some BI or insights kind of applications, you may want to direct a user down a separate path based on the path they have taken and data that is coming in. Some example can be: If data quality/volume is not good enough to display a chart for user to narrow the scope further, take them directly to the next section. Or highlight some entries of significance in the incoming data in a separate section.
Theme: Data Checks Use Case : Form validation. Notes : Some validation can be simply field level ones, but some can get tricky, for e.x. in a data entry form with many sections, the validity of a field may depend on multiple data points contained in other sections. For e.x. you can choose any dates in section 2, but if a particular field in section 1 is set to X, then your dates may be limited to 45 days only.
Theme: Filtering and Sorting
In huge data tables (tables with many columns or complex columns), users may like to filter and sort in arbitrary fashion and it too can get complicated soon.
Disclaimer:
I am not using Redux at the moment, React state management is fine for me at the moment.
This is not an exhaustive list, I will come back and add some more
The text was updated successfully, but these errors were encountered:
I think we need to move away from that terminology altogether. People were thought to think of "business logic" because of design patterns in the form "Rendering, Controller, Everything else", with the "everything else that doesn't fit" being the "business logic"
In patterns like Redux (and many others), things are split by pattern. Eg: a reducer is anything that can be done synchronously from original state and an action. It may or may not be "business logic", but it's split more by lifecycle than concept.
"Can it be done with just dispatch arguments?" -> action creator. "Can it be done with previous state and action?" -> reducer "Can it be done from just state?" -> probably a component. So "where does the business logic lives" -> everywhere.
Where do I put business logic in Redux is a question which still perplexes users. We do have an FAQ entry for it, but with no acceptable definition of what constitutes "Business Logic", it is hard to give concrete advice.
This issue is in response to this tweet . In here, we can collect some real world examples of client side logic and work down that list into what could be construed as business logic.
I am listing below the various kinds of logic I have seen/implemented in my career so far.
UI Visibility or behavior
Use Case : Show/Hide some sections or fields based on the users roles, permissions.
Notes: This can get complicated, with Attribute Based Access Control or other such complex requirements. I personally view it as a representation of UI state and handle it as such.
I usually come across two flavors of this, Application level UI state (for e.x. user is not allowed to edit anything, or view the comments section) or Component/Screen based state (for e.x. user is not allowed to change some field, if the domain object is in state "submitted") .
Use Case : Change the sections to follow based on the data.
Notes : In some BI or insights kind of applications, you may want to direct a user down a separate path based on the path they have taken and data that is coming in. Some example can be: If data quality/volume is not good enough to display a chart for user to narrow the scope further, take them directly to the next section. Or highlight some entries of significance in the incoming data in a separate section.
Theme: Data Checks
Use Case : Form validation.
Notes : Some validation can be simply field level ones, but some can get tricky, for e.x. in a data entry form with many sections, the validity of a field may depend on multiple data points contained in other sections. For e.x. you can choose any dates in section 2, but if a particular field in section 1 is set to X, then your dates may be limited to 45 days only.
Theme: Filtering and Sorting
In huge data tables (tables with many columns or complex columns), users may like to filter and sort in arbitrary fashion and it too can get complicated soon.
Disclaimer:
The text was updated successfully, but these errors were encountered: