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

2.6.0

New features

• ✨ HistoryHandler's restoreState event contains the direction of the history navigation: a negative number representing going back in history, and a positive number for going forward.
• ✨ HistoryHandler's buildState event contains the operation, indicating whether the current state is being replaced, or a new state is being pushed. (#380)
• ✨ RedirectHandler's redirect event provides the setUrl() method, allowing developers to programmatically alter the target URL.

Minor changes and bugfixes

• 🐞 HTML element overrides uniqueness options only if the attribute is explicitly set. (#375)
• 🐞 HistoryHandler no longer replaces the history state with a stale URL after async redirection. (#385)
• 🐞 ScriptLoader hooks more precisely onto the afterUpdate event, executing scripts only from snippets that have actually been updated.
• 🔧 The type of snippet in updateSnippet() has been relaxed to Element. (#379)
• 🔧 Dependencies have been updated and revised, so that Naja now has zero runtime dependencies.

Full Changelog: 2.5.0...2.6.0

2.6.0-beta.0

🚧 This is a beta release to show some changes that should be coming to Naja in near future. Please help me test these changes by installing the beta tag of Naja:

npm install naja@beta

New features

• ✨ SnippetCache tries to cache the raw markup of snippets as returned from the server, prior to applying any afterUpdate changes. (#368)

• ✨ HistoryHandler now includes more information about the history state change: (#380)

  • buildState event includes information about the performed operation (pushState or replaceState),
  • restoreState event includes information about the direction of the user's navigation that triggered the popstate.

Minor changes and bugfixes

• 🔧 Relax the type of snippet in updateSnippet() (#379)
• 🐞UniqueExtension: only override option from element if it has an explicit attribute (#375)

2.5.0

New features

• ✨ There is a new payload event that is dispatched just before success and allows you to configure options for Naja's internal components based on the server response payload.

Minor changes and bugfixes

• 🔧 The options in the interaction event are now prepopulated with configured default options.
• 🔧 AbortExtension has been refactored to better handle multiple concurrent requests.

Full changelog: 2.4.0...2.5.0

2.4.0

New features

• ✨ HistoryHandler is now initialized only when a history-enabled request is made. This should improve interoperability with other history-altering tools, especially when Naja's History API integration is disabled globally. (#362, credits for the original idea go to #356)
• ✨ Complementary to the previous change, the history state produced by Naja is now explicitly marked so.

Minor changes and bugfixes

• 🔧 Type definitions now allow async event listeners.
• 🐞 A potential race condition issue in HistoryHandler has been fixed.

Full changelog: 2.3.0...2.4.0

2.3.0

Changes

• 🔧 The dist package of Naja comes without polyfills that are no longer necessary (#348), making Naja half the size 🎉
  ⚠️ This means that Naja no longer supports legacy Edge and older versions of Safari (< 14). If you still need to support these browsers, you need to include the polyfills in your application codebase. Learn more in #347.

2.2.1

Bugfixes

• 🐞 ScriptLoader: record IDs of scripts loaded on initial page load (#345)