📚 Hyundux‐saga: 자체 미들웨어 비동기처리

소개

hyundux는 비동기 처리에 전체적인 흐름이 방해되지 않도록 만든 client를 위한 상태관리이다. 하지만 Server API나 Local storage같은 외부환경에 접근은 비동기적으로 처리해야한다. 그렇기 때문에 redux-saga에 미들웨어와 중간에 이벤트를 intercept해서 처리한다는 점에 착아하였고, react-query의 병렬적 API 구성에 영향을 받아 구현하였다.

그림 예시

주안점

1. 다양한 비동기로직의 병렬적 동기적 수행 : 어떤 비동기로직이 다른 비동기로직을 불러서 chain을 형성하고 싶지 않았다. 이는 테스트도 어렵고 어떤 사이드이펙트가 발생하는지 예상할 수가 없다. 그래서 병렬적으로 로직이 실행되고 그 값들을 spread하는 방식을 채택하였다.
2. 테스트 용이 : 네트워크나 local stroage를 받는 경우 테스트가 힘들다는 점이 있다. 하지만 비동기 로직과 action을 분리하고 모든 비동기로직의 결과를 action의 넣고 상태관리를 하기 때문에 가각 나눠서 테스트도 가능하게 만들어서 문제를 해결하였다.

hyundux-saga 구조

Story

export type Story = (object: object) => Promise<object>;
export type RunStory = () => Promise<object>;

export function createStory(story: Story, parameter: object): RunStory {
	return function () {
		return story(parameter);
	};
}

1. story : API에 1대1 대응되는 하나의 story로써 함수형태로 작동한다.
2. RunStory : Hyundux-saga 내부에서만 사용되는 타입으로써 리턴값은 saga내에서 실행된다.
3. createStory : component는 story를 직접 실행하지않고 saga가 실행하여서 실행시간을 조절한다.

Saga

class Saga {
  store: Store | null = null;

  constructor(store: Store) {		
    this.store = store;
  }	

  async run(action: (object: object) => Action, stories: RunStory[]) {
    try {
      const asyncResult = await Promise.all(
        stories.map(async (story) => {  return await story();  })
      );
      const newResult = asyncResult.reduce((originObject, newObject) => {
        return { ...originObject, ...newObject };
      }, {});

      this.store?.dispatch(action(newResult));
    } catch (e) {
      console.log(`Saga error: ${e}`);
      throw "some story is problem";
    }
  }
}
const saga = new Saga(store);
export default saga;

• contructor
  1. store를 받아서 초기화한다.
• run
  1. action과 스토리들을 받아서 promise.all을 통해 모든 비동기 처리를 실행하고 리턴 값을 spread해서 action에 전달한다.

문제점

1. 우선 story의 리턴값에 key가 같으면 겹쳐진다.
2. 보일러플레이트가 너무 복잡하다. 보면 action도 그냥 받는게 아니라 액션을 생성하는 함수를 받아야하는것도 이상하고 불편한것 같다.

네이밍
Saga라는것은 redux-saga에서 따온 네이밍이다. 그렇다면 Story? saga는 무용담, 신화와 같은 서사라고 생각했고, 그안에는 story들과 action이 있다고 생각해서 위와같이 네이밍을 지었다.(참고로 내가 만든 네이밍중 가장 맘에 든다.)(아래에서 나오겠지만 실제로 저 saga를 실행하는것도 teller라고 이름을 지었다 ㅎ)

custom hook

type SagaStatus = "isLoading" | "isSuccess" | "isError";
  
const useSaga = () => {
	const [sagaStatus, setSagaStatus] = useState<SagaStatus>("isLoading");
	const teller = async (
	action: (object: object) => Action, 
	stories: RunStory[]
	) => {
		setSagaStatus("isLoading");
		try {
			await saga.run(action, stories);
			setSagaStatus("isSuccess");
		} catch (e) {
			console.log(`saga Error: ${e}`);
			setSagaStatus("isError");
		}
	}
	return [sagaStatus, teller] as const;
};

export default useSaga;

각 전체적인 로딩 상태를 위해 status를 추가해 fetch 상태를 추적할 수 있도록 구현하였고, 대부분 중요한 사항은 saga에서 실행된다.

사용 예시

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

const TestComponent = () => {
	const [state, store] = useWork(initTestState, countReducer);
	const [status, teller] = useSaga();
	
	useEffect(() => {
		setTimeout(() => {
			const testStory = createStory(HealthCheckStory, {});
			teller(action.init, [testStory]);
		}, 5000);
	}, []);
	
	let content = <p> is Loading... </p>;
	
	if (status == "isSuccess") {
		content = <p>{state.data}</p>;
	} 
	else if (status == "isError") {
		content = <p>"error"</p>;
	}
	return content;
};

위처럼 action과 스토리들을 보내면 된다.

추후 수정사항

1. spread할 때 같은 이름의 변수를 써야하고 모든 게 DTO와 이름이 같아야하는게 조금 걸린다.
2. 줄일만큼 줄였지만 보일러 플레이트가 너무 긴거 같다..
3. 컴포넌트 단위로 state를 관리하다보니 해당 state에 대한 의존성문제가 생긴다... 이 점은 고치기 위해 많은 시간이 들것같다.
4. store에 라이플사이클을 좀 더 잘 관리할 수 있도록 만들어야할 것 같다.