v2.4.0 - v2.4.3

Release Notes

The next minor release brings a new exciting feature, plently of improvements and a non-breaking but important change to the API.

At this point, I believe Notivue is feature-complete and most likely there won't be new features in future releases besides improvements and fixes.

New: useNotivueInstance

Consumers can now fully control the Notivue instance by stopping and restarting it.

In .vue components:

<script setup lang="ts">
import { useNotivueInstance } from 'notivue'

const { isRunning, startInstance, stopInstance } = useNotivueInstance()
</script>

In any other module:

import { startInstance, stopInstance } from 'notivue'

This allows the users of an app, for example, to properly enable and disable notifications in total autonomy.

Before this release, this was not "officially" supported and it could be achieved for example, by mounting/unmounting <Notivue /> (e.g. using v-if) but this was not optimal as it would have not stopped the store from "working" in the background, processing unwanted notifications and wasting resources.

This is now done the right way: when the instance is stopped, the whole store is reset, any watcher is detached, any update to the config either via direct setter or via update() is gracefully proxied without throwing errors. Same for push, which is made no-op when the instance is stopped.

Finally, notivue can now be initialized with a startOnCreation option (which defaults to true):

import { createNotivue } from 'notivue'

const notivue = createNotivue({
   startOnCreation: false,
   // Other options
})

If set to false, Notivue won't be started when the app is mounted.

This can be useful to make sure that for some users Notivue is never enabled or to only start it when the environment is ready:

import { updateConfig, startInstance } from 'notivue'

fetch('/api/user-preferences')
   .then((res) => res.json())
   .then((data) => {
      if (data.notifications.isEnabled) {
         startInstance()
         updateConfig(data.notifications.config)
      }
   })

Change: Add transition config property and disable automatic transition property detection

Before this release Notivue automatically computed the transition property added to the containers when repositioning them by "reading" the animationDuration and animationTimingFunction properties of the enter animation as soon as the first notification was rendered.

This logic required about 100 lines of code and added some complexity that could definitely be avoided as the majority of users are not customizing animations at all. This also made the package smaller and more efficient.

Starting from this release, Notivue won't compute anymore the transition property automatically, instead it should be defined manually in the configuration if using custom animations.

const notivue = createNotivue({
  transition: 'transform 200ms ease-out',
})

Check the docs website for more info.

Improvement: Fine-tune repositioning

Notivue handles repositioning of the notifications using a custom approach via CSS transitions and inline styles. Internally, the store includes a method named updatePositions that is called to compute and apply those styles everytime the notifications must be repositioned (creation, clearing, destroy, size-change, etc).

Before this release, such method was called a couple of times more than necessary on both creation and clearing, creating some unnecessary overhead.

By adding a tiny logic that keeps track of the lifecycle events (creation, clearing and destruction), I was able to move the updatePositions logic to a single place of the store in order to make sure that repositoning now happens only once per each of those events.

Improvement: Fine-tune ResizeObserver

Notivue uses the ResizeObserver API to keep track of the size of the containers and to reposition them if needed, for example, when the content of a notification is updated dynamically, all the notifications must be repositioned.

Before this release, the ResizeObserver callback would have repositioned the notifications when they were about to be destroyed, if their size never changed. This was totally unnecessary as it was already handled (as explained in the previous section) and it has been taken care of.

Improvement: Fine-tune pauseOnTabChange: false

Before this release, if pauseOnTabChange was disabled in the config, the notifications would have been immediately destroyed when the window was blurred.

I realized that this not optimal as an user would expect the notifications timeouts to be kept alive and running.

This has been taken care of and the behavior when pauseOnTabChange is disabled is now basically the same as if the user din't left the app.