🎯 Hyundux: 자체 상태관리

소개

hyundux는 기존에 redux가 가지고 있던 전통적인 틀을 가지고 있지만, 각 컴포넌트가 state를 소유하지 않고 page 단위에서 props로 컴포넌트에 내려주고 있었다. 하지만 component에 자체 state의 변화를 줄 수 없다는건 반쪽짜리 컴포넌트 분리라고 생각해서 컴포넌트가 자체적으로 state를 가지고 있고 상태변화도 component가 가지도록 하였다.

그림 예시

주안점

1. 좁은 상태관리 : 기존에 state는 Page 단위로 관리했다. 그리고 대부분 Page라는 부모에서 상태를 모아 관리한다. 하지만 component라는 리액트의 장점을 반만 살린것 같다는 느낌이 들었다. 컴포넌트라는 것은 결국 재사용이 되야하는데 그럴때마다 그 컴포넌트를 가진 페이지에 새로운 로직을 추가하는것은 좋아보이지 않았다. 그래서 컴포넌트 단위의 상태관리를 하기로 하였다.
2. 단방향 상태관리 : 무조건적으로 단방햔이여야했다. 외부 fetch나 local storage같이 클라이언트의 조작범위를 벗어난 기능을 추가하지 않아야했으며 고려하지 않았다. 그러한 클라이언트 외부에서 state를 바꾸게되면 어떤 side effect가 발생할지 모르고 어떤 시점에 state 갱신 될지 모르기 때문에 hyundux자체는 동기적으로 단방향적으로 상태를 변경하기위해 신경썼다.

hyundux store 구조

Store

interface Store {
	states: State<unknown>[];
	reducers: Reducer<unknown>[];
	subscribe: <PayLoad>(
		initState: State<PayLoad>,
		reducer: Reducer<PayLoad> | null,
		cb: (state: State<PayLoad>) => void
	) => void;
	dispatch: <T>(action: Action | DoAction<T>) => void;
	publish: <PayLoad>(oldState: State<PayLoad>, state: State<PayLoad>) => void;
	subscribeList: Map<string, <PayLoad>(state: State<PayLoad>) => void>;
}

1. state: store에 등록된 컴포넌트들의 상태를 저장하는 배열
2. reducer: action들을 각 컴포넌트가 처리하는 방법을 저장한 reducer
3. subscribe: hook에서만 부르는 함수로 초기에 state와 reducer, publish에 등록될 것들을 초기화한다.
4. dispatch: 컴포넌트가 action을 쏴주고 맵핑된 정보들을 통해 state를 변경한다.
5. publish: state가 변경되었음을 알리는 함수이다.
6. subscribeList: 각 컴포넌트에 대한 정보를 담고 있는 배열이다.

현재 dispatch를 제외한 모든 function, property들은 외부에서 접근하지 않는다.

dispatch도 외부에서 직접적으로 접근하지 못하도록 수정할 예정

State & Action & Reducer & DoAction interface

interface State<T> {
	type: string;
	payload: T;
}

interface Action {
	type: string;
	actionName: string;
	payload?: object;
}

interface Reducer<PayLoad> {
	type: string;
	reducer: (state: State<PayLoad>, action: Action) => State<PayLoad>;
}

interface DoAction<T> {
	type: string;
	doing: (state: State<T>) => State<T>;
}

• State
  1. type: 해당 state에 mapping을 위한 key
  2. payload: state에 대한 모든 데이터를 가지고 있는 payload
• Action
  1. type: state에 mapping하기 위한 key
  2. actionName: reducer와 mapping하기 위한 key
  3. payload: 각 action에서 들고 있어야할 데이터를 저장하는 payload
• Reducer
  1. type: state에 mapping하기 위한 key
  2. reducer: state와 action을 받아서 처리하기 위한 함수
• DoAction
  1. type: state에 mapping하기 위한 key
  2. reducer의 switch 부분을 때와서 action에서 처리함

Reducer에 리턴타입이 Promise가 아닌이유
리듀서는 store를 반드시 동기적으로 바꾸게하기 위함이다. 비동기를 reducer에서 처리하게 되면 단방향보단 다방향이 될 것 같아서 reducer에서는 모든 처리를 동기적으로한다. (📚 Hyundux-saga: 자체 미들웨어 비동기처리 여기에서 만든 미들웨어가 action을 잡아서 처리한다.)

DoAction을 만들게 된 이유
사실 상태관리는 무겁다. 다양한 state가 있는것도 아니고 하나의 state이긴 하지만 UI를 변경하는게 아닌 비즈니스로직인 경우가 있을 수 있다. 이런 경우 DoAction은 좀 action에 실제 실행되도록하는 Do를 만들어서 코드응집성은 좋지 않지만 보일러플레이트의 수나 많은 것들이 줄어드는 Do를 만들게 되었다. (flutter에 bloc과 cubit을 참고)

custom hook

function useWork<PayLoad>(
	initialState: HState<PayLoad>,
	reducer: Reducer<PayLoad>
) {
	const [state, setState] = useState<HState<PayLoad>>(initialState);
	store.subscribe(state, reducer, (newState) => {
		setState(newState);
	});
	return state.payload
}

각 상태관리가 필요한 컴포넌트에서 부르는 해당 custom hook을 부르느면 컴포넌트가 subscribe를 함

1. parameters
   • initState: 컴포넌트가 초기에 가지고 있는 상태값들
   • reducer: 각 컴포넌트에 처리하는 reducer

사용 예시

예시는 숫자를 세어주는 counter의 예제이다.

const WORKFLOW_NAME = "Count";
// state type
interface CountPayLoad {
	count: number;
	text: string;
}

const initCountState = createState<CountPayLoad>(WORKFLOW_NAME, {
	count: 0,
	text: "helloWorld",
});

// define reducer
const countReducer: Reducer<CountPayLoad> = {
	type: WORKFLOW_NAME,
	reducer: async function reducer(state, action) {
		const payLoad = state.payload;
		switch (action.actionName) {
			case "countUp":
				return makePayLoad(state, { count: payLoad.count + 1 });
			case "countDown":
				return makePayLoad(state, { count: payLoad.count - 1 });
			case "getText": {
				const actionPayLoad = (action.payload || {}) as { text: string };
				return makePayLoad(state, { text: actionPayLoad.text });
				}
			default:
				return state;
		}
	},
};

// actions
const action = {
	countUp: (): Action => {
		return {
			type: WORKFLOW_NAME,
			actionName: "countUp",
		};
	},
	countDown: (): Action => {
		return {
			type: WORKFLOW_NAME,
			actionName: "countDown",
		};
	},
	getText: (text: string): Action => {
		return {
			type: WORKFLOW_NAME,
			actionName: "getText",
			payload: {
				text: text,
			},
		};
	},
};

// do를 사용할 땐 Reducer가 따로 필요없다.
const doAction = {
	countUp: (): DoAction<CountPayLoad> => {
		return {
			type: Do_NAME,
			doing: (state: State<CountPayLoad>): State<CountPayLoad> => {
				return makePayLoad(state, { count: state.payload.count + 1 });
			},
		};	
	},
};

export { action, initCountState, countReducer };

위처럼 state, reducer, action, doAction 등을 선언하고 사용한다. 위와 같은 형태는 아니더라도 Action, Reducer, State의 타입을 통일시키고 키가되는 WROKFLOW_NAME만 맞추게 되면 잘 작동한다.

추후 수정사항

1. 현재는 dispatch를 store를 직접 접근하는데 이를 custom hook에 넣어서 보내고 직접적으로 store에 접근하는 것을 막아야할 것 같다.
2. 줄일만큼 줄였지만 보일러 플레이트가 너무 긴거 같다..
3. 컴포넌트 단위로 state를 관리하다보니 해당 state에 대한 의존성문제가 생긴다... 이 점은 고치기 위해 많은 시간이 들것같다.
4. store에 라이플사이클을 좀 더 잘 관리할 수 있도록 만들어야할 것 같다.