2024

[qwreey]

quad 는 2021년, 즉 3년 전에 개발되었습니다.
Destroying 이벤트는 2022, 즉 2년전에 출시되었습니다 (정확히는 완전한 릴리즈는 해당 년도 말)

2021 년도 시절에는 quad 와 같은 production ready 의 vdom-less 의 ui 라이브러리가 거의 없었습니다. 퓨전이나 vide 등의 vdom-less 는 모두 Destroying 이벤트에 의존하여 destruction 을 제공합니다. 이는 quad 는 매우 제한적인 환경에서 구축되었음을 의미합니다.

데이터의 소거는 매우 중요합니다. 리스너, 업데이터로 하여금 해당 오브젝트는 소거되었으므로 더이상 업데이트 하지 말아야함을 알리는것은 ui 라이브러리에서 뼈대의 일부입니다.

해당 시절 존재했던 거의 유일한 roact (지금의 react-lua) 를 생각하보세요. 해당 라이브러리는 vdom 을 가지며 라이브러리 사용자는 ui 가 가져야할 모습만을 기재할 뿐, 인스턴스에 대한 직접적 작용은 에상되지 않은 동작이였습니다. 따라서 roact 는 ui 의 생애주기를 이해하고, 소거될 시점을 예상할 수 있었습니다.

그러나 quad 는 완전히 다른것입니다. UI-helper 의 자리로써 사용자는 Instance 와의 작업을 유지하되 해야하는 작업을 편하게 만들어주는 역할이였습니다. store, register 와 같은것이 그 증빙입니다. 유저는 여전히 Instance 를 필요에 맞추어 사용하면서도 편리한것을 얻을 수 있었습니다.

이는 Roact 와 다르게 Quad 가 매우 간단하고 쉬울 수 있던 주된 요인입니다.

하지만 quad 는 더 많은 기능을 제공함에 따라서 관리하기 어려운 위치에 놓였습니다. Destroying 이 없던 시절 quad 는 destruction 을 제공하기 위해서 gc 의 동작에 의존했습니다.

quad 의 내부적 구현은, register 가 어딘가에 적용되는 순간 클로저를 통하여 강한참조가 생성되어지고 이를 이용해 리스너를 유지시키고, 오브젝트가 제거되는 순간, 강한 참조는 제거되어지며 리스너가 제거될 수 있도록 되어있습니다.

즉 이는 매우 어려우며 모호한 코드가 내부적으로 존재하게 만들었습니다. 여기저기 weak table 과 클로저가 넘쳤습니다.

이러한 lua hacky 한 method 는 이제 old tech 이기 때문에 교체될 시기가 왔습니다. 우리는 Destroying 이벤트를 가지고 있습니다. 이를 통해 더 시기적절하게 리스너, 업데이터, 연관 데이터를 소거할 수 있게되었습니다. 당연하게도 해키하지 않은 방법이기에 더 적은 버그와, 더 깔끔한 내부적 구현으로 개발이 가속될 수 있을것입니다.

이 시점에서 quad 의 2.x 시기는 막을 내립니다.

앞으로 구현되어야할 것은 class, slot 입니다. class 의 경우 beta feature 로써 제공되고 있었습니다. 불안정하며 불명확한 곳이 많았습니다. 다시 작성될 필요가 있습니다.

[qwreey]

새로운 quad 에 대해 준비할것은 무엇인가요?

• 일반적으로 없습니다.

quad 는 더이상 register 라는 이름을 사용하지 않을것입니다. 이는 지원이 누락된다는 의미가 아닙니다. 하위 호환성을 위하여 유지되나, 새로운것을 위한 다른 이름이 필요합니다 - 더 명확하고 더 간단한 (예시: state)

또한 2.x 지원을 위한것은 분리가 가능한 형태로 제공될것입니다. 완전히 새롭게 작성되는 경우 사용하지 않아야 하지만, 이전것이 필요한 경우 불러와 사용할 수 있습니다.

이는 quad 의 최대 하위호환성 개발정책에 의한것입니다.