3.3.3

Minor changes and bugfixes

• 🐞 Snippet cache is always initialized when replacing the initial state. (#427, #428, thanks @zipper)

3.3.2

Minor changes and bugfixes

• 🐞 History integration is reinitialized early after page reload. (#424, #425)

3.3.1

Minor changes and bugfixes

• 🐞 Added missing isInitial property to BuildStateEvent type definition. (#422, thanks @zipper)

3.3.0

New features

• ✨ You can now unambiguously distinguish the initial history state update via the isInitial property of the buildState event. (#418, #420)

Minor changes and bugfixes

• 🐞 Naja's history integration is now properly re-initialized after full page reloads. (#418, #420)
• 🐞 Snippet updates are now handled synchronously whenever possible, making for a more predictable order of dispatched afterUpdate event. (#416, #417)

3.2.1

Minor changes and bugfixes

• 🐞 Naja now does a better job at instructing browsers to use the correct title in the history entry. (#406, #407)
• 🔧 The naja package now exports all event types and some other auxiliary types so that you can unleash full strictness onto your TypeScript codebase. (#408)

3.2.0

New features

• ✨ UIHandler.submitForm() helper method now accepts a submitter element as its first parameter, in addition to a form. However, the native form.requestSubmit() method is the recommended way to manually dispatch form submissions to Naja in modern browsers.

Minor changes and bugfixes

• 🔧 UI binding to forms has been simplified (#401, #402, thanks @filiphlm). Naja now does not bind itself onto submitter elements, instead it listens only on submit events of forms. The interaction event's element property continues to refer to the submitter element when available.
• 🔧 Naja switched to the exports field in package.json

Compatibility considerations

Naja continues to hold its compatibility promise of working correctly "in the latest versions of Chromium (Chrome and Edge), Firefox, and WebKit (Safari)."

With this release, Naja newly relies on APIs that might not be available in some older versions of these browsers. If you still need to support these, please check the compatibility and available polyfills for the SubmitEvent.submitter property, and the submitter parameter in FormData() constructor.

3.1.0

New features

• ✨ UIHandler provides a helper called processInteraction() that allows developers to process any custom interactions through Naja, including dispatching the interaction event. (#388)

Minor changes and bugfixes

• 🐞 UIHandler binds onto form buttons without explicit type="submit". (#397)

3.0.0

Naja 3.0 is an evolutionary release and should not come with any breaking changes for the majority of users. The breaking changes are mostly expected to affect advanced users, and developers who build custom extensions on top of Naja.

That said, there have been some changes in the inner workings of the snippet cache that may alter the behaviour, so it is strongly recommended that you properly test your application against the 3.x release.

New features

• ✨ SnippetHandler supports asynchronous snippet update operations, such as using View Transitions API. (#383) You can now wrap snippet updates in transitions, and rely on Naja dispatching the afterUpdate event only after the update has been completed.

  • SnippetHandler dispatches a new pendingUpdate event. The event is dispatched right before the now asynchronous update is invoked, and only if the update has not been prevented in the beforeUpdate event.

  • ⚠️ BREAKING CHANGE: if you are using SnippetHandler.updateSnippet() or SnippetHandler.updateSnippets() method directly, please note that the method is now asynchronous and the DOM is guaranteed to be updated only after its returned promise resolves.

  • ⚠️ BREAKING CHANGE: due to the asynchronicity, it is no longer guaranteed that all snippets have been updated by the time success and complete events are dispatched.

• ✨ SnippetCache stores raw snippet content. (#368) This makes snippet restoration more deterministic for snippet update event listeners.

  The afterUpdate event is the preferred way to e.g. initialize third-party scripts and widgets. Previously, snippet cache wasn't populated until after updating the snippets, and thus snippets stored in the cache might already have contained these DOM modifications; as a result, the same afterUpdate listener would receive different inputs in different scenarios: one pristine when updating from the server, and one already modified when restoring the snippet from cache during history navigation.

  In Naja 3.0, snippets are cached in the original form whenever possible, so that afterUpdate event listeners receive the same, unaltered input, regardless of where it comes from.

  • ⚠️ BREAKING CHANGE: if you are implementing your own snippet update operation, it is now expected to be an object implementing a pair of methods:

    • updateElement(snippet: Element, content: string): void | Promise<void>

      This method should just wrap the original, pre-3.0 snippet update operation: it updates the snippet element with the content received from the server. As per the previous section, the update can now be asynchronous.

    • updateIndex(currentContent: string, newContent: string): string

      This method has been added to integrate with the enhanced snippet cache capabilities. It applies the newContent received from the server onto the snippet's cached currentContent, and returns the result. This method works entirely with the raw snippet contents, no DOM involved.

      For example, the built-in replace operation implements this method so that it returns newContent, whereas the append operation does return a concatenation of currentContent + newContent.

    Current snippet update operation implementations are backward-compatible, with updateIndex() falling back to simply returning newContent received from the server. It is recommended that you update your implementation to include the newly added method, so that you have full control over the implementation and its behaviour.

3.0.0-rc.1

This is a release candidate of the upcoming Naja 3.0. This is an evolutionary release and should not come with any breaking changes for the majority of users. The breaking changes are mostly expected to affect advanced users, and developers who build custom extensions on top of Naja.

That said, there have been some changes in the inner workings of the snippet cache that may alter the behaviour, so it is strongly recommended that you properly test your application against the 3.x release, and report any issues.

New features

• ✨ SnippetHandler supports asynchronous snippet update operations, such as using View Transitions API. (#383) You can now wrap snippet updates in transitions, and rely on Naja dispatching the afterUpdate event only after the update has been completed.

  • SnippetHandler dispatches a new pendingUpdate event. The event is dispatched right before the now asynchronous update is invoked, and only if the update has not been prevented in the beforeUpdate event.

  • ⚠️ BREAKING CHANGE: if you are using SnippetHandler.updateSnippet() or SnippetHandler.updateSnippets() method directly, please note that the method is now asynchronous and the DOM is guaranteed to be updated only after its returned promise resolves.

  • ⚠️ BREAKING CHANGE: due to the asynchronicity, it is no longer guaranteed that all snippets have been updated by the time success and complete events are dispatched.

• ✨ SnippetCache stores raw snippet content. (#368) This makes snippet restoration more deterministic for snippet update event listeners.

  The afterUpdate event is the preferred way to e.g. initialize third-party scripts and widgets. Previously, snippet cache wasn't populated until after updating the snippets, and thus snippets stored in the cache might already have contained these DOM modifications; as a result, the same afterUpdate listener would receive different inputs in different scenarios: one pristine when updating from the server, and one already modified when restoring the snippet from cache during history navigation.

  In Naja 3.0, snippets are cached in the original form whenever possible, so that afterUpdate event listeners receive the same, unaltered input, regardless of where it comes from.

  • ⚠️ BREAKING CHANGE: if you are implementing your own snippet update operation, it is now expected to be an object implementing a pair of methods:

    • updateElement(snippet: Element, content: string): void | Promise<void>

      This method should just wrap the original, pre-3.0 snippet update operation: it updates the snippet element with the content received from the server. As per the previous section, the update can now be asynchronous.

    • updateIndex(currentContent: string, newContent: string): string

      This method has been added to integrate with the enhanced snippet cache capabilities. It applies the newContent received from the server onto the snippet's cached currentContent, and returns the result. This method works entirely with the raw snippet contents, no DOM involved.

      For example, the built-in replace operation implements this method so that it returns newContent, whereas the append operation does return a concatenation of currentContent + newContent.

    Current snippet update operation implementations are backward-compatible, with updateIndex() falling back to simply returning newContent received from the server. It is recommended that you update your implementation to include the newly added method, so that you have full control over the implementation and its behaviour.

2.6.1

Minor changes and bugfixes

• 🐞 SnippetCache no longer needs to call loadScripts() manually since ScriptLoader now hooks directly onto snippet's afterUpdate event.

Full Changelog: 2.6.0...2.6.1