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

• warn that IDOM_FEATURE_INDEX_AS_DEFAULT_KEY=1 will be the default - #515
• clean up patch queues after exit - #514
• Remove Reconnecting WS alert - #513
• Fix #502 - #503

0.33.2

A release to fix a memory leak caused by event handlers that were not being removed
when components updated.

Closed Issues

• Non-root component event handlers cause memory leaks - #510

0.33.1

A hot fix for a regression introduced in 0.33.0 where the root element of the layout could not be updated. See #498 for more info. A regression test for this will be introduced in a future release.

Pull Requests

• Fix #498 pt1 - #501

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:

1. Removal of large chunks of code
2. 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.
3. 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.
4. 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 of IDOM_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 down idom.web module
• The IDOM_CLIENT_BUILD_DIR config option will no longer exist and a new IDOM_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

• Fix typo in index.rst - #411
• add event handlers docs - #410
• misc doc improvements - #409
• port first IDOM article to docs - #408
• Test build in CI - #404
• Remove all runtime reliance on NPM - #398

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
  the createElement, render, unmountComponentAtNode functions from React.

Issues Fixed:

• #375
• #394
• #401

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 to idom-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 means idom-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 of importSource.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 to import()