|
1 | 1 | Changelog
|
2 | 2 | =========
|
3 | 3 |
|
| 4 | +0.31.0 |
| 5 | +------ |
| 6 | + |
| 7 | +The :class:`~idom.core.layout.Layout` is now a prototype, and ``Layout.update`` is no |
| 8 | +longer a public API. This is combined with a much more significant refactor of the |
| 9 | +underlying rendering logic. |
| 10 | + |
| 11 | +The biggest issue that has been resolved relates to the relationship between |
| 12 | +:class:`~idom.core.hooks.LifeCycleHook` and ``Layout``. Previously, the |
| 13 | +``LifeCycleHook`` accepted a layout instance in its constructor and called |
| 14 | +``Layout.update``. Additionally, the ``Layout`` would manipulate the |
| 15 | +``LifeCycleHook.component`` attribute whenever the component instance changed after a |
| 16 | +render. The former behavior leads to a non-linear code path that's a touch to follow. |
| 17 | +The latter behavior is the most egregious design issue since there's absolutely no local |
| 18 | +indication that the component instance can be swapped out (not even a comment). |
| 19 | + |
| 20 | +The new refactor no longer binds component or layout instances to a ``LifeCycleHook``. |
| 21 | +Instead, the hook simply receives an unparametrized callback that can be triggered to |
| 22 | +schedule a render. While some error logs lose clarity (since we can't say what component |
| 23 | +caused them). This change precludes a need for the layout to ever mutate the hook. |
| 24 | + |
| 25 | +To accomodate this change, the internal representation of the layout's state had to |
| 26 | +change. Previsouly, a class-based approach was take, where methods of the state-holding |
| 27 | +classes were meant to handle all use cases. Now we rely much more heavily on very simple |
| 28 | +(and mostly static) data structures that have purpose built constructor functions that |
| 29 | +much more narrowly address each use case. |
| 30 | + |
| 31 | +After these refactors, ``ComponentTypes`` no longer needs a unique ``id`` attribute. |
| 32 | +Instead, a unique ID is generated internally which is associated with the |
| 33 | +``LifeCycleState``, not component instances since they are inherently transient. |
| 34 | + |
| 35 | +**Pull Requests** |
| 36 | + |
| 37 | +- fix #419 and #412 - :pull:`422` |
| 38 | + |
4 | 39 |
|
5 | 40 | 0.30.1
|
6 | 41 | ------
|
|
0 commit comments