DEV Community: MasuqaT

Event handlers should be optional

MasuqaT — Mon, 18 Oct 2021 12:42:54 +0000

I realized that a component still works fine even if they do not receive event handlers. I explain why making event handlers optional makes sense and recommend doing it.

Component's event handlers to whom?

The event handlers of a component are defined for the caller, the parent component.

Thinking about the necessity of the events and event handlers in the component, they are used to realize the inverse data flow. Since "components should only update their own state", when it receives the data from its parent, indirectly expresses an update as an event, notifies it to its parent through the callback a.k.a. event handler, ask its parent to update the data. ref: Thinking in React - Step 5: Add Inverse Data Flow

Be aware that the event handlers, passed from the parent, do not affect directly on the (child) component. Of course, it looks as if it affects the (child) component when they are combined in the app, however, just the parent component changes itself instead of the (child) component. The parent component receives an event from the child through the event handlers, changes its state base on the event, then finally passes the updated data to the child. The parent component do not necessarily have to utilize the event and still be able to pass arbitrary data to the (child) component. Including whether to utilize the event or not, the update logic is fully under the parent's decision. In other words, the child component should not know about how the events and the event handlers are used in the parent component or others ¹. Even if the event handler is undefined because of not passed from the parent, the child component does not change its self behavior.

Actually, all the event handlers for HTML elements are optional. We don't need to use focusin or input event and pass event handlers to all the events (except framework development). Moreover, HTML elements still work fine (raise no errors) even though we don't pass event handlers.

Since Vue and Angular use HTML based notation, event handlers are naturally regarded as optional. While in React, because it expresses event handlers as props like a value, event handlers tend to be marked as required. To avoid that, we need to call event handlers with optional chaining (?.) thoroughly, then add ? to the type if in TypeScript.

That said, isn't it necessary sometimes?

I believe everything will be still well even if we make all "event handlers" optional.

Function prop doesn't mean event handler

The type of the event handlers may be like (...args: [...Args]) => void, returns nothing. In some cases, the props includes normal functions which are not event handlers. For example, data fetching function (...args: [...Args]) => Promise<Data>². These functions are required for the component to work fine. However, they are actually not event handlers and not related to this opinion, event handlers should be optional.

Component in cooperative group

As I mentioned that, even though the component is assumed to be work cooperatively in practice with the parent or others through the event handlers, receiving event handlers does not mean they are required for the single component (might be useless for others without passing event handlers). Passing event handlers is necessary to realize the behavior for a cooperative group, but as the parent-child relation of the component, as I mentioned above, it is just the problem how the cooperative group uses the event and not the problem of the single component as a primitive piece in the group.

Similarly in HTML elements, for example of <button type="button" />, (in normal use) it is not useful without use of click event, but that button does not raise an error. Because the parent component cannot achieve the requirement without click event or others, it pass event handlers to that button.

Inconvenience of required event handlers

Lastly, I list problems if event handlers are not optional.

Component catalog or test

In a component catalog, we explain many variations of the component. If event handlers are required, we have to pass made-up event handlers³ though they are not necessary in a catalog. Maybe, notifying the emit of the event is helpful only in the demo for behavior and not helpful for explaining color or size variants. (Remember that the long list of code for color and size variation of a basic button component with onClick={action("clicked")} in each item.)

The same is true for the test. If event handlers are required, we have to pass unnecessary event handlers for the test view point and the test purpose goes unclear. Also it increases boilerplate even in a test.

Conditionally unnecessary

Depending on the parameters, sometimes it is obvious that there are event handlers which are never called. For example, click event when <button /> is disabled. Aside from why⁴ there are permanently disabled control elements in SPA, it is a bad interface for a component user that has obviously unnecessary event handlers but necessary to pass something.

Previously, I put const noop = () => {}; to the required onChange prop of <input />-like component which is sometimes permanently disabled for the fixed value. I still regret doing that.

As an interface which satisfies the requirement, e.g. the identifier names and parameters, the components need to "reach the consensus" with its generic(unspecified) parent. ↩
I think most of the components should receive fetched data as a value prop, not through invoking a function prop. ↩
Usually they are just a boilerplate such as Storybook Actions or console.log. ↩
E.g. listing uneditable values along with normal editable values, brief promotion with button like "Coming Soon", etc. ↩

Component variant with View-Hook Pair

MasuqaT — Sun, 05 Sep 2021 12:55:58 +0000

Japanese Version | 日本語版

In my previous post, I introduced View-Hook Pair pattern. In this post, I describe how to implement a component with some variations with View-Hook Pair. Using it, we can achieve the modular frontend component without lacking the flexibility of spec change or refactoring-ability.

Example code

Variation of the component

During creating a web application, there are the visually similar component with almost the same usecase and the same place. It is because that, some parts look/behave a bit different according to its attribute, feature flags, customize by users, and so on.

In this post, I bring up the example of a simple file viewer app with the component with the 2 variations. This app has 2 panes, the file list on the left and the detail on the right. Especially for an image file or a movie file, the detail pane additionaly shows the thumbnails (actually a made-up image).

At this time, I regard the difference of the detail pane as a variation.

Problem

Of course we hope all the components are highly maintainable. However, for the component shared part of the variants, it is hard. The spec change could leads code changes in many place due to duplication and/or forgetting the necessary changes. It costs more and has higher congnitive load than the usual components. We need to avoid them somehow.

Though there are several naive implementation for the component with the variants, it would cause problems when the component gets complex/large.

Code changes in many place or miss by the duplication when the variants are implemented with the respective components.
Difficult to change by the branch conditions when the varitants are implemented as the single component which changes UI/behavior by the parameters.
The component requires unnecessary props for some variants and it is difficult to express as the type.
Though we initially achieve the good shared parts or the good branch flows, it won't be that good after it adds many features.

I assume View-Hook Pair ease these problems.

View-Hook Pair

View-Hook Pair is, I previously proposed, an idea for divide-and-conquar method which consists with the formmaly defined pair of View and Hook. The former covers UI code and the latter covers state and logic.

In this post, I defined the "Standard form" against the problem like this.

function useObject({}: Props, {}: Dependencies): [ViewProps, Exports] {
  return [{}, {}] as const;
}
function View({}: ViewProps): ReactElement {
  return <div />;
}
export const Component = { useObject, View };

I newly propose the objects Dependencies and Exports. These are optional to use and we are also be able to implement the example project without these objects.

The former object Dependencies would be the port of Dependency Injection pattern. This is to the component free from the (static and technically detailed) external dependency with the side-effect and/or resource fetching, like the server layered architecture.

The latter object Exports would be the public methods/properties of Object-Oriented Programming class. These useObject "class" exchange messages with others through their "public" interfaces.

When to integrate the pair, integrate it in where it is used. For example, the component which uses Component with non View-Hook Pair form and the unit tests.

Tactics

From here, I describe how to implement the pair using child pairs.

First, make the normal component for the shared part. We don't need to use View-Hook Pair for a (simple) Presentational component or the one only with small logic and scoped state. If not and necessary, like "Standard form" above, split the component into the pair. That said, usually we just put the component states and callbacks to ViewProps, the functions run in useEffect like componentWillMount to Exports, and declarative UI (including animation state) to View, respectively.

In a View-Hook Pair form component which uses View-Hook Pair form components, combine Views and Hooks independently.

function useObject({}: Props, {}: Dependencies): [ViewProps, Exports] {
  const [childProps, childExports] = Child.useObject({}, {});
  return [{ childProps }, {}] as const;
}
function View({ childProps }: ViewProps) {
  return <Child.View {...childProps} />;
}
export const Parent = { useObject, View };

In useObject in the parent component, it combines its Prop, Dependencies, and children's useObjects and Exportss to implement its responsibility. In View, using HTML element and other component, it places children's Views and mark up its whole look. Maybe, its ViewProps has some structure to prevent the flood of flat children's ViewPropss.

At the top component which finally integrates the pair to the normal form, like Component_ above, call useObject, do necessary process, then finally call View.

The flow of process is like this.

(Actually, the order is arbitrary for the Views in the same depth.)

In the tree of Hook side, the parent Hook can create its ViewProps and Exports by referencing children's encapsulated states from Exportss, in postorder. It is difficult to achieve with normal React component method except with redundant(duplicated) statea. In the tree of View side, the tree structure is almost the same and rendered in the similar order.

Example through the project

I pick some code for the component implementing variants from Example code. For the rest of the component, check 'src/Panel'. I don't mention the other components because it is off-topic.

As I mentioned the example project in the first section of this post, its detail pane has 2 variations which is for media files and for others. In this example, they are implemented separatedly as MediaPanel and TextPanel respectively (both components are located in 'src/Panel'). Both are "Parent" in the figure above and they share their contents in 'src/Panel/parts', except the spacing and the behavior/UI only in one.

First, I show the TextPanel which is easier. (Style definitions are excluded because it is off-topic.)

type Props = { name: string };
type Dependencies = {};
function useObject({ name }: Props, {}: Dependencies) {
  const [attributesProps] = Attributes.useObject({ name }, {});
  return [{ name, attributesProps }];
}
function View({ name, attributesProps }: ReturnType<typeof useObject>[0]) {
  return (
    <div>
      <div>
        <Header name={name} />
      </div>
      <div>
        <Attributes.View {...attributesProps} />
      </div>
    </div>
  );
}
export const TextPanel = { useObject, View };

It uses normal form Header shared component and View-Hook Pair form Attributes shared component. I placed <div /> to add spacing because it is responsibility of this component.

Then, I show the Hook of MediaPanel.

type Props = { id: string; name: string };
type Dependencies = { getPreviewUrl: (id: string) => Promise<string> };
function useObject({ id, name }: Props, { getPreviewUrl }: Dependencies) {
  const [previewUrl, setPreviewUrl] = useState<string>();
  const [previewProps] = Preview.useObject({ previewUrl }, {});
  const [attributesProps, { editing: attributesEditing }] = Attributes.useObject({ name }, {});
  const load = useCallback(async () => {
    setPreviewUrl(undefined);
    setPreviewUrl(await getPreviewUrl(id));
  }, [id, getPreviewUrl]);
  return [{ name, attributesEditing, previewProps, attributesProps }, { load }] as const;
}

It additionally uses Preview shared component because MediaPanel has a preview not like TextPanel. Then, MediaPanel has a requirement to stop the animation during editing Attributes, so it uses Exports of Attributes.useObject. Furthermore, it exports load in Exports to make the parent be able to control the load timing of it.

Finally, I show the View of MediaPanel.

function View({
  name,
  attributesEditing,
  previewProps,
  attributesProps,
}: ReturnType<typeof useObject>[0]) {
  const [previewHovered, setPreviewHovered] = useState(false);
  return (
    <div>
      <div className={previewHovered && !attributesEditing && style}>
        <Header name={name} />
      </div>
      <div onMouseEnter={() => setPreviewHovered(true)} onMouseLeave={() => setPreviewHovered(false)}>
        <Preview.View {...previewProps} />
      </div>
      <div>
        <Attributes.View {...attributesProps} />
      </div>
    </div>
  );
}

It just pass the props for the children's ViewPropss. Apart from that, it has previewHovered state for the UI decoration. (View-Hook Pair is to sweep out information state and logic from View and it doesn't mean to prohibit any kind of state. The state and logic are allowed which is only for the decoration.)

Cons

Though it helps the essential part (in sence the of spec) to be well shared, this pattern forces many boilerplates.
Conditional or loop process. This is due to React Hooks restriction. It also could be a problem when the View and Hook is located in the different depth in the tree.
Typing for the pair. Declaring all the type and impose the pair or referring the actual implementation dynamically. (This example uses latter one.)

Summary

To explain the usage of View-Hook Pair, I describe the implementation for the component with variations to prevent the maintainability problem.

Separate Presentation "System" first in the frontend architecture

MasuqaT — Sun, 04 Jul 2021 11:38:06 +0000

Japanese Version | 日本語版

I am working on the SPA which is becoming fat and complex due to its (proper and necessary) requirement and difficulty. I want to manage the problems before they become too big to deal with.

In this article, I try to re-introduce the rough structure to the frontend architecture, between the UI components and API access objects, to divide them and ease the complexity. I hope this helps you to organize the problems, to review the code, and to avoid "unnecessary" consideration.

Problem

I observed that the practice such as layering, UI component classification, and component composition is widely spread among the community today for the middle size components. By putting the responsibility of the visual to the Presentational Component, the logic/data process is well managed in the Container Component. It reduces the chance of mixing the visual and logic/data process, which leads it to the "legacy" code.

On the other hand, I sometimes feel that there is no good rule nor guideline in the codebase between the UI components and the API access objects. When the logic/data process becomes fat, we would use the library called the Store such as Redux + async plugin, MobX, and (your favorite library) to ease the complexity. Though with that, the store becomes fat/complex too unless there is a good rule. These fatness/complexity usually would not be recognized until the new members point out it or they get confused. It is also the high congnitive load for whom understands codebase well, due to the team mates' change.

2 kinds of Store

I assume that the one of the cause of fatness/complexity, in the large codebase between the UI components and the API access objects, is the mix of the 2 responsibilities in the name of Store.

The responsibility of external data access and caching
- Accessing API to fetch data and holding it. The Repository.
- Its data will not change unless executing write operations.
The responsibility of storing UI states and managing them
- A global store which its data keep over the page transition.
- Its data will change anytime by user's UI operation or some machine events.

For example, we assume there is a search page with "Search" button at the center and the facet view at the left, the store with the first responsibility should have the search condition data which indicates the current search result, and the one with the second responsibility should have the search condition draft which indicates the current UI state.

I remember that the past configuration of Redux + async plugin combination usually tends to mix both of them in the same store/module. If they are separated into these reducers, it may be okay.

From here, I call the store with the first
responsibility as Repository and the another one as "UI Store".

There are several technologies, of course, we just use them considering the kinds above. Though there is a right tech in the right place, I think we can choose them freely to the 2 kinds of "Store" (including the choise of the same tech).

Hook based store
- useState or useReducer in the component
- Custome hook
- The global store with "constate" or self-made Redux-like store.
Redux
- vanilla (plain)
- async plugin such as redux-thunk
Data access class (including MobX)
GraphQL library with caching feature
Data resource of React Concurrent mode

Example: Using a data resource of React Concurrent mode as the Repository and using a custome hook as the "UI Store".

Separate Presentation "System"¹

When the store layer becomes fat/complex and there are multiple different responsibilities, concerns, or systems in it, they should be separated; draw the dividing line between the Repository and the "UI Store". This is not a new idea. In the application server architecture, we usually follow the rule that separates the presentation layer (the view in MVC) from others. With the exception of the interface/contract, the Repository should not know what happens in the Presentation System, and vice versa.

It does not mean better or not, but I just list up possible implementations². In Pattern 1, "UI Store" is the bridge between the Repository and the Presentation System. In Pattern 2, the Container Component, and stateless hook called in it, combines the data flow from the Repository to the "UI Store".

Though there are other perspectives of dividing codebase, I believe that only few methods conflict with this Presentation System separation. Of course it requires the kind of dependency injection to avoid the conflicts as usual. By separating the Presentation System as the first step, I believe, we can still easily separate the codebase with other perspective and the problem becomes smaller by removing the typical mix of the responsibility first.

Using reactive object such as Rx

Do it outside of the Presentation System. We should depend on the reactivity only provided by the view library (React, Vue, etc.) in the inside of the system.
Separating Command/Query like frontend CQRS

Do it outside of the Presentation System. We should consider the data flow separately with Flux, in the system.
Concentric layered architecture³

Do it outside of the Presentation System. The presentation system corresponds to the outer layer(shell) since it is the presentation⁴.
DDD in frontend

Do it outside of the Presentation System. Maybe the system depends on either the primitive values or DDD domain models and/or usecases⁵.
Various component design patterns

It should be closed in the Presentation System. I have not seen the component design pattern which crossing the system boundary.
Component library/framework

It should be closed in the Presentation System.

Summary

I described that we can divide the store into the 2 parts, the Repository and the "UI Store", and the codebase will be simpler if separating the Presentation System from others first.

It's too large to call it as a "layer", so I call it as a "system". Moreover, just using presentation "layer" seems like that its target is only around the Presentational Component. ↩
Initially I started writing this article with Pattern 1 in mind. However, I currently feel that Pattern 2 will be the mainline through the layer division of Container Component in the future. ↩
Such as Hexagonal Architecture, Clean Architecture, and Onion Architecture. ↩
I believe, however, the most important part is the Presentation System in frontend. ↩
To be honest, I do not have an experience of DDD in frontend. This is just a wild guess. ↩

View-Hook Pair Pattern (Draft)

MasuqaT — Sat, 20 Feb 2021 03:06:11 +0000

Japanese Version | 日本語版

I recently "came up with" a new React design pattern. In this post, I just want to show you the method because it seems it will take a lot of time to write the whole background, problem and pros/cons.

For the large chunk of the process, it is relatively "easy" to separate them by considering the layer and/or their concern. However, it is not easy for the frontend components due to other kinds of problem. I (roughly) "propose" a new divide-and-conquer pattern named "View-Hook Pair" to solve them.

Large Frontend Component

Imagine the SPA app which has many large components; these components interact each other in the sense of the logic and UI. Whenever the user opens/closes <ProjectPane /> tab, its content should be look the same. In other words, the internal UI state of <ProjectPane /> should not be reset after its mounting and unmounting. To satisfy these UI requirements, we want to shape up the structure which the parent of <ProjectPane /> have bare minimum of the control.

Maybe we are going to achieve it by using Redux or some data store or by controlling all the states and logics (which ideally the parent should not concern) in the parent. It is difficult to separate them not just only styling the code but also improving the maintainability; loosely coupling and high cohesion.

View-Hook Pair Pattern

For the problem, I "propose" a new divide-and-conquer pattern named "View-Hook Pair". As the name suggests, a pair is made by React JSX and React Hook. The former only controls UI code and latter only controls states and logics. Both may be exported and used from outside. I think this kind of pattern is used in the public already. I just reorganize them as a bit abstract pattern.

Mainly a pair consists of items below. (The variable names in the example code has no special meaning.)

UI code as View
States & logics as Hook
(if necessary) Integration code of the pair and/or Type definition of inter-pair-item interface

It could be regarded as the gradual Model-View-ViewModel(MVVM) pattern using Hook.

View

export const View = ({ enabled, enable, disable, /* ... */ }: PresentationModel) => (
  <div>
    <input type="text" disabled={disabled} />
    <div>
      <button type="button" onClick={enable}>Enable</button>
      <button type="button" onClick={disable}>Disable</button>
    </div>
  </div>
);

In View item in the pair, it has all UI code in the component and written in a pure "state -> UI" function. It receives arguments from Hook result (in mind) and returns JSX.

By separating the component to the UI code only chunk, it is easy to do unit tests and make visual catalog like Storybook story. In a naïve View, it contains the structure definition (HTML/XML) and the style definition (CSS). So we can separate View more to the layers.

Hook

export const usePresentationModel = ({}: Args): PresentationModel => {
  const [enabled, setEnabled] = useState(false);

  const enable = useCallback(() => { setEnabled(true); }, []);
  const disable = useCallback(() => { setEnabled(false); }, []);
  // other definitions...

  return { enabled, enable, disable, /* ... */ };
};

In Hook item in the pair, it has all the states and logics and written in a Custom Hook. It receives arguments of dependencies and/or initial values and returns values/callbacks to View in mind.

By separating the component to states and logics only chunk, it is easy to do unit tests. When the hook gets fat, we can separate Hook to sub hooks by concerns like the method described in useEncapsulation | Kyle Shevlin and/or putting a reducer or a data-access layer as plain "Model" (at least in the interface type) to the backward. Doing latter one, this Hook is regarded as "buffer zone" between React code and non-React code, like original MVVM ViewModel.

Basic form of integration

export const Container = () => {
  const presentationModel = usePresentationModel();
  return <View {...presentationModel} />;
};

The basic form of the integration of the pair is just passing the Hook result to View. It can be okay to do integration test with it.

The integration code should let pair-items concentrate on their concerns as much as possible.

Examples

It is not easy to explain the merits with a small code example because this pattern is for the large components. Here, I will show the example utilizing this pattern inside of the component or outside of the component. (These are not limited to the page component.)

As testable separation for the component

export const Page = ({ userName, changeTheme }: Props) => {
  const { initialize, ...presentationModel } = usePageLogics({ changeTheme });

  useEffect(() => { initialize(); }, []);

  return <PageView {...presentationModel} userName={userName} />;
};

It is possible to use a part of result from Hook in useEffect to call some process after Page mount (initialize in the example). It is okay to mix Hook result values with props and/or context; values not from Hooks. (No overuse!)

When to make more layers in usePageLogics, do DI in Page and avoid usePageLogics depends directly on Context, Redux, Router or etc.

As described above, we can test both pair-items and integration code easily.

I reviewed and wrote a page component with this pattern in my work and the guy; who uses layered architecture in server side; said it is clear and easy to understand.

As divide-and-conquer in the component

const Page = () => {
  const [isPaneOpen] = useState(false);
  const projectListProps = useProjectList();

  return (
    <ProjectListContext.Provider value={projectListProps}>
      <div>/* deep */
        {isPaneOpen && <div><PaneContent /></div>}
      /* deep */</div>
    <ProjectListContext.Provider>
  );
};

const PaneContent = () => {
  const projectListProps = useContext(ProjectListContext);

  return <div><ProjectList {...projectListProps} /></div>;
};

The problem; the difference of the desired place for UI code and the desired place for the data lifecycle; is solved by separating the component to the pair and place pair-items separately. In the example above, the state of <ProjectList /> will not change after toggling to isPaneOpen === false condition. It is not necessary to prepare a global store and transform models only to achieve these requirements; keeping state and divide-and-conquer.

Of cource, we can mix Hook result values with a local state or something in the place among <Page /> and <LeftPane />, so we can adjust values a bit easily. (In easy case, Unstated Next is helpful.)

Although View and Hook are placed separately in the parent component, we can do unit test and "integration test" by writing the integration code for the test.

Unfortunately, it is still in experimental phase for me because some questions below perhaps indicate warning and a next evolutional pattern.

Current questions

(Like ViewModel in MVVM) The inter-pair-items interface type is exposed outside. This is good at adjusting but the same time, is it okay in sense of divide-and-conquer?
If the component is enough small, the plain coupled form is easy and fast to implement. How to make a tradeoff?
No example to split a large pair to the child pairs. Is it easy to split as same as a plain coupled component?
Unknown potentials with using React Server Component. Is is still useful with it?

DEV Community: MasuqaT

Event handlers should be optional

Component's event handlers to whom?

That said, isn't it necessary sometimes?

Function prop doesn't mean event handler

Component in cooperative group

Inconvenience of required event handlers

Component catalog or test

Conditionally unnecessary

Component variant with View-Hook Pair

Variation of the component

Problem

View-Hook Pair

Tactics

Example through the project

Cons

Summary

Separate Presentation "System" first in the frontend architecture

Problem

2 kinds of Store

Separate Presentation "System"1

Summary

View-Hook Pair Pattern (Draft)

Large Frontend Component

View-Hook Pair Pattern

View

Hook

Basic form of integration

Examples

As testable separation for the component

As divide-and-conquer in the component

Current questions

Separate Presentation "System"¹