javascript의 꽃 비동기, closure

js의 꽃은 비동기다. 그리고 꽃의 꿀은 closure가 아닐까? 이전엔 그저 framework에 맞춰가며 비동기를 생각하다가 이제 스스로 promise 객체를 만들다 보니 다시금 그 중요성을 느껴가는 중이다.

여기서 closure가?

export default function App() {
  const [loadingCount, setLoadingCount] = useState(0);
  const [todoList, setTodoList] = useState([]);

  const fetchTodoList = () => {
    console.log('start1' + loadingCount);
    setLoadingCount(loadingCount + 1);
    console.log('start2' + loadingCount);

    fetch(Constants.expoConfig.extra.apiServer + '/todos', {
      method: 'GET',
      headers: {
        Accept: 'application/json',
      },
    })
      .then((res) => {
        if (!res.ok) throw new Error(res.status);

        return res.json();
      })
      .then((body) => {
        const { message, data } = body;
        if (!data) throw new Error(message);

        setTodoList(data);
      })
      .catch((err) => {
        ToastAndroid.show(
          'fail to fetch todo list, please re-start application',
          ToastAndroid.LONG
        );
      })
      .finally(() => {
        // 이게 closure라고...
        console.log('end1' + loadingCount);
        setLoadingCount(loadingCount - 1);
        console.log('end2' + loadingCount);
      });
  };

  useEffect(() => {
    console.log('call' + loadingCount);
    fetchTodoList();
  }, []);

  useEffect(() => {
    console.log('render' + loadingCount);
  });

  return (
    <View>
    </View>
  );
}

오늘 비로소 react useCallback의 필요성을 깨달았다. 그리고 node가 '비동기'적으로 동작한다는 사실을 다시 한번 되짚어봤다. 비동기... closure란 정말 멋있는 존재다.

Event Driven Architecture

이제 promise 말고 event driven 설계를 해보고 싶다. 하지만 아직까진 객체 instance가 필요할 일이 잘 없어 아쉽다. literal object를 사용한다면 method를 쓰지 event handler를 쓸 이유가 없다. 사실 어떤 유형의 프로그램에서 event 기반의 객체가 필요할지 모르겠다. 그나마 game이 가능성이 높지 않을까? 어쩌면 적절한 디자인 패턴을 아직 모르는 걸지도 모르겠다.

js를 배운다는 것

js를 공부한다는 건 비동기와 closure를 알아가는게 아닐까?

과거 promise를 안다고 착각했던 나, promise의 동작 원리를 깨닫고 기뻐하던 나, promise를 framework 안의 부품으로만 대하던 나, async만 쓰며 promise keyword를 싫어하던 나, 그리고 이제 promise를 직접 만드는 나와 eventemitter를 기대하는 내가 있다.