Releases: reactive-python/reactpy
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.client
is being removed in favor of a stripped downidom.web
module - The
IDOM_CLIENT_BUILD_DIR
config option will no longer exist and a newIDOM_WEB_MODULES_DIR
which 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.
Pull Requests
0.29.0
Contains breaking changes, the most significant of which are:
- Moves the runtime client build directory to a "user data" directory rather a directory
where IDOM's code was installed. This has the advantage of not requiring write
permissions to rebuild the client if IDOM was installed globally rather than in a
virtual environment. - The custom JS component interface has been reworked to expose an API similar to
thecreateElement
,render
,unmountComponentAtNode
functions from React.
Issues Fixed:
Highlighted Commits:
- add try/except around event handling - f2bf589
- do not call find_builtin_server_type at import time - e29745e
- import default from react/reactDOM/fast-json-patch - 74c8a34
- no named exports for react/reactDOM - f13bf35
- debug logs for runtime build dir create/update - af94f4e
- put runtime build in user data dir - 0af69d2
- change shared to update_on_change - 6c09a86
- rework js module interface + fix docs - 699cc66
- correctly serialize File object - a2398dc
0.28.0
Includes a wide variety of improvements:
- support
currentTime
attr of audio/video elements - support for the
files
attribute from the target of input elements - model children are passed to the Javascript
mount()
function - began to add tests to client-side javascript
- add a
mountLayoutWithWebSocket
function toidom-client-react
and breaking changes, the most significant of which are:
- Refactor existing server implementations as functions adhering to a protocol. This greatly simplified much of the code responsible for setting up servers and avoids the use of inheritance.
- Switch to a monorepo-style structure for Javascript enabling a greater separation of concerns and common workspace scripts in
package.json
. - Use a
loadImportSource()
function instead of trying to infer the path to dynamic modules which was brittle and inflexible. Allowing the specific client implementation to discover where "import sources" are located meansidom-client-react
doesn't need to try and devise a solution that will work for all cases. The fallout from this change is the addition ofimportSource.sourceType
which, for the moment can either be"NAME"
or"URL"
where the former indicates the client is expected to know where to find a module of that name, and the latter should (usually) be passed on toimport()