Releases: reactive-python/reactpy
0.35.0
The highlight of this release is that the default "key" of all elements will be their index amongst their neighbors. Previously this behavior could be engaged by setting IDOM_FEATURE_INDEX_AS_DEFAULT_KEY=1 when running IDOM. In this release though, you will need to explicitely turn off this feature (i.e. =0) to return to the old behavior. With this change, some may notice additional error logs which warn that:
Key not specified for child in list ...
This is saying is that an element or component which was created in a list does not have a unique key. For more information on how to mitigate this warning refer to the docs on "Organizing Items With Keys".
Closed Issues
Pull Requests
0.34.0
This release contains a variety of minor fixes and improvements which came out of rewriting the documentation. The most significant of these changes is the remove of target element attributes from the top-level of event data dictionaries. For example,
instead of being able to find the value of an input at event["value"] it willinstead be found at event["target"]["value"]. For a short period we will issue a DeprecationWarning when target attributes are requested at the top-level of the event dictionary. As part of this change we also add event["currentTarget"] and event["relatedTarget"] keys to the event dictionary as well as a
event[some_target]["boundingClientRect"] where some_target may be "target", "currentTarget" or "relatedTarget".
Closed Issues
- Move target attributes to
event['target']- #548
Pull Requests
0.33.3
0.33.3
Contains a small number of bug fixes and improvements. The most significant change is the addition of a warning stating that IDOM_FEATURE_INDEX_AS_DEFAULT_KEY=1 will become the default in a future release. Beyond that, a lesser improvement makes it possible to use the default export from a Javascript module when calling module_from_template by specifying exports_default=True as a parameter.
Closed Issues
- Memory leak in SharedClientStateServer - #511
- Cannot use default export in react template - #502
- Add warning that element index will be used as the default key in a future release - #428
Pull Requests
0.33.2
0.33.1
0.33.0
The most significant fix in this release is for a regression which manifested in #480, #489, and #451 which resulted from an issue in the way JSON patches were being applied client-side. This was ultimately resolved by #490. While it's difficult to test this without a more thorough Javascript suite, we added a test that should hopefully catch this in the future by proxy.
The most important breaking change, is yet another which modifies the Custom Javascript Component interface. We now add a create() function to the bind() interface that allows IDOM's client to recursively create components from that (and only that) import source. Prior to this, the interface was given unrendered models for child elements. The imported module was then responsible for rendering them. This placed a large burden on the author to understand how to handle these unrendered child models. In addition, in the React template used by module_from_template we needed to import a version of idom-client-react from the CDN - this had already caused some issues where the template required a version of idom-client-react in the which had not been released
yet.
Closed Issues
- Client-side error in mount-01d35dc3.js - #489
- Style Cannot Be Updated - #480
- Displaying error messages in the client via
__error__tag can leak secrets - #454 - Examples broken in docs - #451
- Rework docs landing page - #446
- eventHandlers should be a mapping of generic callables - #423
- Allow customization of built-in IDOM client - #253
Pull Requests
- move VdomDict and VdomJson to proto - #492
- only send error info in debug mode - #491
- correcly apply client-side JSON patch - #490
- add script to set version of all packages in IDOM - #483
- Pass import source to bind - #482
- Do not mutate client-side model - #481
- assume import source children come from same source - #479
- make an EventHandlerType protocol - #476
- Update issue form - #471
0.32.0
In addition to a variety of bug fixes and other minor improvements, there's a breaking change to the custom component interface - instead of exporting multiple functions that render custom components, we simply expect a single bind() function. binding function then must return an object with a render() and unmount() function. This change was made in order to better support the rendering of child models.
Closed Issues
- Docs broken on Firefox - #469
- URL resolution for web modules does not consider urls starting with / - #460
- Query params in package name for module_from_template not stripped - #455
- Make docs section margins larger - #450
- Search broken in docs - #443
- Move src/idom/client out of Python package - #429
- Use composition instead of classes with Layout and LifeCycleHook - #412
- Remove Python language extension - #282
- Add keys to models so React doesn't complain of child arrays requiring them - #255
- Fix binder link in docs - #231
Pull Requests
- Update issue form - #471
- improve heading legibility - #470
- fix search in docs by upgrading sphinx - #462
- rework custom component interface with bind() func - #458
- parse package as url path in module_from_template - #456
- add file extensions to import - #439
- fix key warnings - #438
- fix #429 - move client JS to top of src/ dir - #430
0.31.0
The Layout is now a prototype, and Layout.update is no longer a public API. This is combined with a much more significant refactor of
the underlying rendering logic.
The biggest issue that has been resolved relates to the relationship between LifeCycleHook and Layout. Previously, the LifeCycleHook accepted a layout instance in its constructor and called Layout.update. Additionally, the Layout would manipulate the LifeCycleHook.component attribute whenever the component instance changed after a render. The former behavior leads to a non-linear code path that's a touch to follow. The latter behavior is the most egregious design issue since there's absolutely no local indication that the component instance can be swapped out (not even a comment).
The new refactor no longer binds component or layout instances to a LifeCycleHook. Instead, the hook simply receives an unparametrized callback that can be triggered to schedule a render. While some error logs lose clarity (since we can't say what component caused them). This change precludes a need for the layout to ever mutate the hook.
To accomodate this change, the internal representation of the layout's state had to change. Previsouly, a class-based approach was take, where methods of the state-holding classes were meant to handle all use cases. Now we rely much more heavily on very simple (and mostly static) data structures that have purpose built constructor functions that much more narrowly address each use case.
After these refactors, ComponentTypes no longer needs a unique id attribute. Instead, a unique ID is generated internally which is associated with the LifeCycleState, not component instances since they are inherently transient.
0.30.1
Removes the usage of the id() function for generating unique ideas because there were situations where the IDs bound to the lifetime of an object are problematic. Also adds a warning Deprecation warning to render functions that include the parameter key. It's been decided that allowing key to be used in this way can lead to confusing bugs.
0.30.0
Summary
With recent changes to the custom component interface, it's now possible to remove all runtime reliance on NPM. Doing so has many virtuous knock-on effects:
- Removal of large chunks of code
- Greatly simplifies how users dynamically experiment with React component libraries, because their usage no longer requires a build step. Instead they can be loaded in the browser from a CDN that distributes ESM modules.
- The built-in client code needs to make fewer assumption about where static resources are located, and as a result, it's also easier to coordinate the server and client code.
- Alternate client implementations benefit from this simplicity. Now, it's possible to install idom-client-react normally and write a
loadImportSource()function that looks for route serving the contents ofIDOM_WEB_MODULES_DIR.
This change includes large breaking changes:
- The CLI is being removed as it won't be needed any longer
- The
idom.clientis being removed in favor of a stripped downidom.webmodule - The
IDOM_CLIENT_BUILD_DIRconfig option will no longer exist and a newIDOM_WEB_MODULES_DIRwhich only contains dynamically linked web modules. While this new directory's location is configurable, it is meant to be transient and should not be re-used across sessions.
The new idom.web module takes a simpler approach to constructing import sources and expands upon the logic for resolving imports by allowing exports from URLs to be discovered too. Now, that IDOM isn't using NPM to dynamically install component libraries idom.web instead creates JS modules from template files and links them into IDOM_WEB_MODULES_DIR. These templates ultimately direct the browser to load the desired library from a CDN.