React & GraphQL with MVP
Tags: react, graphql, typescript, architecture
Published: 2022-08-17 14:45:00

I have created a simple thread app using an MVP pattern. The features are:
- Authorization
- Posting information on threads.
- Searching users by email

I will share the architectural knowledge I have acquired in the process.
Feel free to download it from its [Github repository](https://github.com/umemaryu/react-graphql-mvp).

## MVP

Before starting, I have to say that I adopted the [Passive View](https://martinfowler.com/eaaDev/PassiveScreen.html), not the [Supervising Controller](https://martinfowler.com/eaaDev/SupervisingPresenter.html). Anyway, let’s grasp the points of the MVP. MVP stands for Model-View-Presenter and is used mainly for building user interfaces. Each layer role:
- The Model is responsible for application logic and data management.
- The Presenter acts as a bridge between the View and the Model.
- The View contains only UI presentation and the logic - components, local state, button clicks, etc. In other words, you should not include any application logic here. 

![Model-View-Presenter](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w2s2tkjeww6s8jlqle9h.jpg)

They enable the separation of concerns between the application and the UI. It means complicated tasks are broken down into simple ones. Besides, you can do unit tests. However, keep in mind that the MVP is not a magic bullet. It has disadvantages such as the increase in the interfaces.

I felt it was a great concept and decided to adopt the pattern, but it was little abstract. On that occasion, I found the below practical image in  Khalil Stemmler’s article. I referred to his ideas a lot. 


![Client-Side Architecture Basics](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/po13nze3wluwuuqu13so.png)
Image credits: [khalilstemmler.com](https://khalilstemmler.com/articles/client-side-architecture/layers/)


## Folder structure

You consider each directory in the root of the src as follows.

- components/ - react components 
- pages/ - most of them are also containers
- interactions/ - interaction(application) logics
- infra/ -  state management and communicating with server-side
- hooks/ - shared custom hooks
- providers/ - application providers
- routes/ - routes configuration
- types/ - type aliases
- utils/ - shared utility functions


## View

### Components/
Components are categorized into Elements and Others.

#### Components/Elements/

Minimum components are defined such as Input and Button. I used [Chakra UI](https://chakra-ui.com/) and [React Icons](https://react-icons.github.io/react-icons/) for the UI libraries, and only this folder depends on them. (Of course, it is necessary to import the hooks and providers from other places). As a result, if you need to replace them with other libraries, you can do it smoothly because the dependencies concentrate on the folder. 

I just wrapped the libraries' components basically but customized its props as needed.

```tsx
// components/Elements/Button/Button.tsx

import { Input as ChakraInput, InputProps } from "@chakra-ui/react";

type Props = Omit<InputProps, "onChange"> & {
	id: string;
	onChange: (value: string, id: string) => void;
};

export const FormInput = ({ id, onChange, ...props }: Props) => (
	<ChakraInput
		{...props}
		size="lg"
		onChange={(e) => onChange(e.target.value, id)}
	/>
);

```



#### Components/Others/

These presentational(UI) components consist of Elements and the other components. I have separated the stateful logic from the presentation by React Hooks to distinguish the roles visually. In the hooks, you deal with event handlers, page navigation, local(component) state management, etc. If you develop a medium or larger project, I suggest you create a new folder for the logic (the hooks) in order to keep the readability. 

Regarding style strongly dependent on the application design, such as the application brand colors, it is better to have a global style state considering modifiability.

```typescript
// components/Sections/AccountSection.tsx

import { useCallback, useState } from "react";
import { Box, Button, Center, Text } from "components/Elements";
import { theme } from "utils/theme";
import { ThreadLayout } from "components/Layout";
import { Form } from "components/Form";
import { ChangePassword, SignOut } from "types";
import useCustomToast from "hooks/useCustomToast";
// ...
const useAccount = ({ id, actions }: Input) => {
	const list = [
		// ...
	];

	const initValue = {
		oldPassword: "",
		newPassword: "",
	};
	const [state, setState] = useState(initValue);

	const { setSuccess } = useCustomToast();

	const handleUpdatePassword = async () => {
		await actions.changePassword({
			id: id,
			...state,
		});
        // if handleUpdatePassword throws error,
        // below setSuccess and setState won't run.
		setSuccess({ title: "Password changed ", description: "" });
		setState(initValue);
	};

	return {
		models: { list, state },
		operations: { handleFormInput, handleUpdatePassword, handleSignOut },
	};
};

// ...

export const AccountSection: React.FC<Props> = ({ id, actions, error }) => {
	const { models, operations } = useAccount({ id, actions });
	return (
		<ThreadLayout page="Account">
			// ...
			<Button
				onClick={operations.handleUpdatePassword}
				w={"100%"}
				mb={theme.m.md}
			>
				Update Password
			</Button>
			// ...
		</ThreadLayout>
	);
};
```

## Presenter

### pages/
This directory plays a role in containers/presenters as well as pages. However, note that it is different from the presentational/container pattern. In the design, the container handles the entire component logic. Unlike the conventional definition, this container is a bridge between a View and a Model. It is responsible for delegating user actions from the View to Models, to be specific, to interactions, and passing data to View.

```typescript
// pages/Account.container.tsx

import { useAuth, useUser } from "interactions";
import { AccountSection } from "components/Sections";
// ...
export const Account = ({ id }: Props) => {
	const { operations: authOperations } = useAuth();
	const { error, operations: userOperations } = useUser();
	const { signOut } = authOperations;
	const { changePassword } = userOperations;
	return (
		<AccountSection
			actions={{ signOut, changePassword }}
			id={id}
			error={error}
		/>
	);
};


```

It is few, but some pages may not need the presenters because the view and the model do not communicate. For example, a 404 page is not a container in this project.


## Model

### interactions/
Interaction(application) logic is described. It includes:
- logical decision
- validation
- app calculation
- format conversion

```typescript
// interactions/useUser.ts

import {
	MutationUpdatePasswordArgs,
	QueryFetchUserByEmailArgs,
} from "infra/codegen";
import { useUserOperations } from "infra/operations";
import { useState } from "react";
import { passwordValidation } from "utils/passwordValidation";

export const useUser = () => {
	const [error, setError] = useState("");
	const { models, queries, mutations } = useUserOperations();
	const { user } = models;

	const changePassword = async (args: MutationUpdatePasswordArgs) => {
		const oldPasswordError = passwordValidation(args.oldPassword);
		const newPasswordError = passwordValidation(args.newPassword);
		const errorMessage = oldPasswordError || newPasswordError;
		if (errorMessage) {
			setError(errorMessage);
			return;
		}
		await mutations.updatePassword(args);
	};
	// ...
	return {
		models: { user },
		error,
		operations: { changePassword, searchUser },
	};
};
```

### Error handling

Maybe you put API error logic in the interaction layer or similar place, but I used a global state for them inside of useClient. They are detected automatically, so you do not need to write them. If errors themselves or the UI logic are complex, you had better create the respective error handlings in this layer. 


```typescript
// hooks/useClient.ts

import { useMemo } from "react";
import { ApolloClient, ApolloLink, createHttpLink } from "@apollo/client";
import { setContext } from "@apollo/client/link/context";
import storage from "utils/storage";
import { onError } from "@apollo/client/link/error";
import { cache } from "infra/stores/cache";
import useCustomToast from "hooks/useCustomToast";

const useClient = () => {
	// ...
	const errorLink = useMemo(() => {
		return onError(({ graphQLErrors, networkError }) => {
			if (graphQLErrors) {
				graphQLErrors.map(({ message, locations, path }) => {
					if (path && path[0] !== "fetchUserByToken") {
						setError({
							title: `${message}`,
							description: "Will you please try one more time?",
						});
					}
					return console.log(
						`[GraphQL error]: Message: ${message}, Location: ${locations}, Path: ${path}`
					);
				});
			}
			if (networkError) {
				setError({
					title: `${networkError.message}`,
					description: "Will you please try one more time?",
				});
				console.log(`[Network error]: ${networkError}`);
			}
		});
	}, [setError]);

	const client = useMemo(() => {
		return new ApolloClient({
			// You should care the order of below links!
			link: ApolloLink.from([errorLink, authLink, httpLink]),
			cache: cache,
			connectToDevTools: true,
		});
	}, [httpLink, authLink, errorLink]);
	return { client };
};

export default useClient;

```

### infra/

Infrastructure is a layer that accesses the server-side and manages data. I chose [Apollo Client](https://www.apollographql.com/) for that. According to the official, 

> Apollo Client is a comprehensive state management library for JavaScript that enables you to manage both local and remote data with GraphQL. Use it to fetch, cache, and modify application data, all while automatically updating your UI.

### 4 steps for Apollo code generator.

[GraphQL Code Generator](https://www.graphql-code-generator.com/plugins/typescript/typescript-react-apollo) is handy. It generates the typed Queries, Mutations, and Subscriptions from the GraphQL schema. 

#### 1. Schema
Design type schema - User, Post, Query, and Mutation. [The detail](https://graphql.org/learn/schema/#type-language)

```typescript
// infra/schema.gql

type User {
	id: ID!
	token: String
	email: String!
	password: String!
	country: String!
	city: String!
	nickName: String!
	posts: [Post!]!
}

// ...
```

#### 2. Query and Mutation
One of the differences between Rest API and GraphQL is the number of endpoints. The former has multiple endpoints containing its own URI(Uniform Resource Identifier). In contrast, GraphQL needs only one. How does the system identify each request content? The answer is to describe the exact data structure expected as a response in the query or mutation. The architecture concept prevents over-fetching and under-fetching data. 

Apollo Studio is a good choice for testing queries and mutations. 

> 
[Apollo Studio](https://www.apollographql.com/docs/studio/) is a cloud platform that helps you build, validate, and secure your organization's graph.

```
// infra/mutations/user.gql

// ...
mutation CreateUser(
	$email: String!
	$password: String!
	$country: String!
	$city: String!
	$nickName: String!
) {
	createUser(
		email: $email
		password: $password
		country: $country
		city: $city
		nickName: $nickName
	) {
		token
	}
}
// ...
```

#### 3. codegen.yml
Inform the code generator of the path of the schema, queries, and mutations
 
```yml
schema: src/infra/schema.gql
documents:
  - src/infra/queries/*.gql
  - src/infra/mutations/*.gql
generates:
  src/infra/codegen.ts:
    plugins:
      - typescript
      - typescript-operations
      - typescript-react-apollo
  server/codegen.ts:
    // ...

```

#### 4. Script in package.json
Add this script in the package.json and enter `yarn generate` on your terminal.

```javascript
   "scripts": {
        "generate": "graphql-codegen"
    },
```


### infra/operations

This is in charge of data access by using useMutation and useQuery generated through the code generator described just before. In addition, you modify cache and reactive variables in this layer.

#### Loading and Error
Apollo Client has loading and error about API communication, and you can use them without creating by yourselves.

```typescript
// infra/operations/usePostOperations.ts

import {
	FetchUserByEmailDocument,
	FetchUserByTokenDocument,
	MutationCreatePostArgs,
	useCreatePostMutation,
} from "infra/codegen";
import { cache } from "infra/stores/cache";
import { User } from "types";
// ...
export const usePostOperations: () => { mutations: Mutations } = () => {
	const [CREATE_POST_MUTATION] = useCreatePostMutation();
	const createPost: (
		args: MutationCreatePostArgs,
		user: User,
		queryName: "fetchUserByToken" | "fetchUserByEmail"
	) => Promise<void> = async (args, user, queryName) => {
		await CREATE_POST_MUTATION({
			variables: args,
		}).then((res) => {
			if (!res.data) throw new Error("Response data is undefined");
			const posts = user.posts;
			const newPost = res.data.createPost;
			const query =
				queryName === "fetchUserByToken"
					? FetchUserByTokenDocument
					: FetchUserByEmailDocument;
			cache.updateQuery({ query }, () => ({
				[queryName]: {
					...user,
					posts: [newPost, ...posts],
				},
			}));
		});
	};
	return { mutations: { createPost } };
};

export default usePostOperations;

```

### infra/stores/

You can use Apollo Client cache and reactive variables instead of Redux and React Hooks for store and state management. 

#### How to handle client-side state
You sometimes have to manage the state used only client-side such as a post date converted from a timestamp. By adding @client to the date, you can deal with the client-side state and the query response together. It removes redundant code and clears up the data handling.


```
// infra/queries/user.gql

query FetchUserByEmail($email: String!) {
	fetchUserByEmail(email: $email) {
		id
		email
		country
		city
		nickName
		posts {
			id
			body
			createdAt
			senderEmail
			date @client
		}
	}
}
```

It must also be written which field of the cache will be modified when the queries or mutations run.

```typescript
// infra/stores/cache.ts

import { InMemoryCache } from "@apollo/client";
import { timestampToDate } from "utils/timestampToDate";

export const cache = new InMemoryCache({
	typePolicies: {
		Post: {
			fields: {
				date: {
					read(_, opts) {
						const timestamp = (opts.readField("createdAt") as number) * 1000;
						const date = timestampToDate(timestamp);
						return date;
					},
				},
			},
		},
	},
});
```

## Others

### providers/
All providers consolidate into this folder.

```typescript
// providers/AppProvider.tsx

import { ChakraProvider } from "@chakra-ui/react";
import { Suspense } from "react";
import { ErrorBoundary } from "react-error-boundary";
import { BrowserRouter as Router } from "react-router-dom";
import { IconContext } from "react-icons";
import { theme } from "utils/theme";
import { ApolloProvider } from "@apollo/client";
import useClient from "hooks/useClient";
// ...
export const AppProvider = ({ children }: Props) => {
	const { client } = useClient();
	return (
		// ...
		<ChakraProvider>
			<ApolloProvider client={client}>
				<IconContext.Provider value={{ color: theme.color.blue, size: "32px" }}>
					<Router>{children}</Router>
				</IconContext.Provider>
			</ApolloProvider>
		</ChakraProvider>
		// ...
	);
};

```

### routes/
I split the routes into protected, public, and redirect.

```typescript
// routes/index.tsx

import { useRoutes } from "react-router-dom";
import { publicRoutes } from "routes/public";
import { protectedRoutes } from "routes/protected";
import { useAuth } from "interactions";
import { Error404 } from "pages";
import { authStore } from "infra/stores/authStore";

export const AppRoutes = () => {
	const { loading } = useAuth();
	const id = authStore();
	const routes = id ? protectedRoutes(id) : publicRoutes;
	const redirectRoutes = [
		{ path: "*", element: <Error404 loading={loading} id={id} /> },
	];

	const element = useRoutes([...routes, ...redirectRoutes]);
	return <>{element}</>;
};

```

This figure explains the routes logic.

![Routes navigate figure](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u68ms19zkvoarqb6t8wz.jpg)

## Conclusion
The MVP pattern makes the individual layer roles distinct and reduces the scope of library dependencies. Consequently, the app becomes loose coupling and improves its maintainability.

## References

### Sources
- [bulletproof-react](https://github.com/alan2207/bulletproof-react)

### Articles
- [Client-Side Architecture Basics [Guide]](https://khalilstemmler.com/articles/client-side-architecture/introduction/)
- [Presentational and Container Components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
- [Automatically handling Apollo Client errors in your React UI](https://shinesolutions.com/2021/06/30/automatically-handling-apollo-client-errors-in-your-react-ui/)