Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Gaining clarity on "business logic" for FAQs #2796

Closed
Dubes opened this issue Jan 17, 2018 · 1 comment
Closed

Discussion: Gaining clarity on "business logic" for FAQs #2796

Dubes opened this issue Jan 17, 2018 · 1 comment

Comments

@Dubes
Copy link

Dubes commented Jan 17, 2018

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
@markerikson
Copy link
Contributor

Relevant set of tweets from Francois Ward: https://twitter.com/FwardPhoenix/status/952971237004926977

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants