Skip to content

Commit 718ca9b

Browse files
committed
changelog for 0.31.0
the prior commit message saying as much actually referred to 0.30.1
1 parent 0d43a2e commit 718ca9b

File tree

1 file changed

+35
-0
lines changed

1 file changed

+35
-0
lines changed

Diff for: docs/source/changelog.rst

+35
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,41 @@
11
Changelog
22
=========
33

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+
439

540
0.30.1
641
------

0 commit comments

Comments
 (0)