paradise_lost.md

UI should be an afterthought

What this logic separation gives?

• Better testability via the fewer levels of indirection. To trigger business processes you call methods or invoke functions, not clicking buttons.
• Better testability via DI in some form. In React code jest.mock is the only "unobtrusive" way to replace dependencies.
• Discoverability. Business logic isn't scattered across a bunch of components.
• Reusability. Sometimes you want to reuse only business logic and not the UI tied to it.
• Readability. It is easier to reason about business logic.

How UI benefits from this?

• Specs became ligther. Now you can test only business process call and be sure that all logic variations are already have been tested.
• You already have this DI mechanism built. And you can reuse it in UI specs and Storybook and be sure that you have enoguh control and nothing unexpected (ajax calls, navigation events) will happen.
• Readability. It is easier to reason about UI.

What else should I know?

• Connection logic is still have to be written. How to access properties and methods of business logic stores?
• Mocking logic is still have to be written. Every time you add any external service (session storage interaction, new ajax call, new mutation, etc), there is really high possibility that you have to write some kind of mock to make sure that your existing infrastructure (specs, stories) still work.
• When you are using already "Connected" component you lose any kind of control over it. In most cases this is fine. High chance that it was a deliberate decision, since you wanted both UI and business logic tied to it. Nice thing is that you can turn this "Connected" component into "injectable" service and replace it with mock anytime you like.

What was the problem? Can you repeat please?

• Write code that allows to sepearate business logic frow UI.
• Write code that allows to inject any hard-to-test, too-verbose, want-this-mocked stuff logic.

Why such a strange gist name?

• Because with MobX we had every problem solved:
  • Stores as classes
  • Stores combination via OO composition
  • Store logic reuse via traits
  • Convention for DI via object constructors
  • Convention for intialization via initialize method
• And even more:
  • observable fields
  • and so, ability to build logic over data (observe field change and add reaction to that change). Which feels really declarative