Ting 이네 Software 이야기

 ngrx/store 6.0.1 / Angular 6.x

 ngrx/store 를 처음 써 보는 중에 만나 이슈인데... 어찌보면 당연하긴 하겠지만... 뭔가 magic을 기대하기도 했는데.. 어쨌든...

createSelector(<state>, <action>) 이렇게 될때,  <state> 는 하위의 변화를 detecting하지는 못하는 걸로 보인다. 즉.

state: {
    inner: {
        a: true
    }
}

의 경우

createSelect(state => state.inner, inner => inner.a)

이렇게 해 놓고, dispatch를 통해서, state.inner.a = false 로 하면
selector의 Observer가 fire되지 않는다. 즉, inner.a 는 바뀌었으나, state.inner는 바뀐게 아니라는...

이때 states reference 자체가 reducer에서 바뀌는 경우.. 즉

return state;

가 아니라

return {...state}

가 되면 state의 reference다 바뀌므로 Observer가 fire된다.

Environment: Angular 6.x, Angular Material 6.x

Tooltip애 show 된 이후, Tooltip value에 undefined가 들어가게 되면, 이후 tooltip이 비활성화 되는 것으로 material tooltip component가 처리하는 것으로 보인다.
따라서,
    - html -
    [matTooltip]="myTooltip"

이렇게 한 경우,
tooltip이 'show'된 이후, myTooltip값이
    'a' => 'b' => 'c'
이 순서로 바뀌면, 'c'가 tooltip으로 잘 보이는데,
    'undefined' => 'b'
순서로 replace하면, 'b'가 보이지 않는다. 첫번째 undefined로 인해서, tooltip이 disable되어 버리는 것 같다.

이 경우, mouse를 leave했다가, 다시 enter해서 tooltip이 다시 'show'될 경우, 'b'가 보인다.
즉, 현재 show session에서는 update되지 않고, 다음 'show' session에 보인다.
이것은
    'a' => undefined => 'c'
순서로로 변경할 경우도 마찬가지다 - 당시 show session에서는 'c'가 보이지 않는다.

Sub module은 내가 어디에 붙어 있는지 몰라야 한다.  즉 module "내부" => "외부" 로 dependency가 없어야 한다. 따라서, Inter-Module Communication은 상위 module을 통하는게 좋아 보인다.

                      +--------------------+
              +------->  Parent  Module    +---+
              |       +---------+----------+   |
              |                 |              |
Parent Module is observing    Notify         Notify
              |                 |              |
    +---------+-+     +---------v-+     +------v---------+
    | Module A  |     | Module B  |     | ...            |
    +-----------+     +-----------+     +----------------+

이 경우, 문제는 Lazy-loading module이다.

Lazy-loading module의 Concept상, Parent Module (이 경우, Root Module)에서 Notify를 할 수 없고 해서도 안된다 - Notify를 하려면, loading을 해야하는데... 그럼 더 이상 lazy loading이 아니다!

(만약 해야할 필요가 있다면, Lazy-loading으로 만들면 안된다. )

따라서, Lazy-loading module의 경우, 일반적인 sub-module의 제약사항에 더불어 추가적으로, 다음의 조건이 필요하지 않나... 싶다.(아직 좀더 많은 공부가 필요하다.)

- App. singleton provider 를 사용하면 안된다.

- module이 loading되었음을 가정한, "외부 => module" 로 communication이 없어야 한다.

<= 이거 상당히 강력한 제약사항이다!!!

그리고, 이건: "Inter-lazy-loading module간 communication이 없어야 한다." 를 의미하기도 한다.