@uiloos/core 1.5.0

It is now easier to use "uiloos" with vanilla JavaScript or TypeScript.

As you know when not using a reactive framework such as React or Svelte you manually have to sync the changes with the DOM. To make this easier and with less code: this release introduces a new concept: a subscriber creator function. These functions create subscribers for you, which have an easier to use method based API.

What they do is convert events to method calls.

This allows you to write considerably less code because you no longer need to write a lot of if-statements, or one giant switch statements to determine which event took place.

For example before 1.5.0 you would write:

function subscriber(carousel, event) {
  // Start the progress animation
  if (event.type === 'INITIALIZED') {
    // Code here
  }

  // Halt the animation when paused
  if (event.type === 'AUTO_PLAY_PAUSED') {
    // Code here
  }

  // and resume when playing
  if (event.type === 'AUTO_PLAY_PLAYING') {
    // Code here
  }

  // Remove the progress indicator now that the user has
  // assumed full control over the carousel.
  if (event.type === 'AUTO_PLAY_STOPPED') {
    // Code here
  }

  if (event.type === 'ACTIVATED') {
    // Code here
  }
}

And now you can write it like this:

const subscriber = createActiveListSubscriber({
  onInitialized(event, carousel) {
    // Start the progress animation
    // Code here
  },

  onAutoPlayPaused(event, carousel) {
    // Halt the animation when paused
    // Code here
  },

  onAutoPlayPlaying(event, carousel) {
    // Resume the animation when playing
    // Code here
  },

  onAutoPlayStopped(event, carousel) {
    // Remove the progress indicator now that the user has
    // assumed full control over the carousel.
    // Code here
  },

  onActivated(event, carousel) {
     // Code here
  }
});

You should use a subscriber creator whenever you find that you are creating / need to handle a lot of events from the components. Where each event is handled separately and in isolation, and where each event is updating the DOM with laser precision.

When your subscriber nukes the DOM by clearing it and rebuilds the DOM from scratch, in JavaScript / TypeScript, and on each event. It is easier to use the single (old) subscriber approach.

Each component now has a subscriber creator function:

1. A. The ActiveList has the createActiveListSubscriber function.
2. B. The ViewChannel has the createViewChannelSubscriber function.
3. C. The Typewriter has the createTypewriterSubscriber function.

ActiveList now knows which item was deactivated the last.

This is useful when you want to animate the exit of an content within the ActiveList. Say for example that you have a carrousel and only one item it shown at a time, you can animate the last deactivated item out of the screen, and the last activated item onto the screen.

This is tracked in three new variables:

1. A. lastDeactivated: which value was the last value to be deactivated.
2. B. lastDeactivatedContent: which ActiveListContent was the last to be deactivated.
3. C. lastDeactivatedIndex: the index which was last deactivated.

All components now have an unsubscribeAll method which unsubscribes all subscribers at once.

This is most useful when using uiloos/core directly: it allows all the subscribers to be cleared when you know a component is no longer used.

The ActiveList now has an oppositeDirection live property, its value is always the opposite of what the direction is.

This is useful for animations such as carousels in which you want the previous active slide to move in the opposite direction of the activated slide.

The activateByPredicate and deactivateByPredicate both always fired the ActiveListActivatedMultipleEvent even when nothing changed.

For example: in an ActiveList in which all items are active, when calling activateByPredicate and all items match the predicate: nothing really changes since all items are already active, and in this case no event should be fired.

In 1.5.0 checks are put in place to make sure not event is fired when nothing has changed. This way subscribers are only informed when there are changes.

This only affected you if you used either activateByPredicate or deactivateByPredicate.

The activateByIndex emits an ActiveListActivatedEvent but did not include information about which item was deactivated.

A deactivation can occur when the ActiveList's maxActivationLimit is set to a number, and the maxActivationLimitBehavior is set to "circular". In this scenario whenever more items are activated than alloted, the first item that was activated gets deactivated, in a first in first out manner.

To fix this since this version two new properties are added to the ActiveListActivatedEvent: deactivatedValue and deactivatedIndex.

This only affected you if you used activateByPredicate, and maxActivationLimit was set to a number, and the maxActivationLimitBehavior was set to "circular".

The activateByPredicate emits an ActiveListActivatedMultipleEvent but did not include information about which items were deactivated.

A deactivation can occur when the ActiveList's maxActivationLimit is set to a number, and the maxActivationLimitBehavior is set to "circular". In this scenario whenever more items are activated than alloted, the first item that was activated gets deactivated, in a first in first out manner.

To fix this since this version two new properties are added to the ActiveListActivatedMultipleEvent: deactivatedValues and deactivatedIndexes.

This only affected you if you used activateByPredicate, and maxActivationLimit was set to a number, and the maxActivationLimitBehavior was set to "circular".

The activateByPredicate would not send out an ActiveListActivatedMultipleEvent when an ActiveListActivationLimitReachedError was thrown.

The error can be thrown when the ActiveList's maxActivationLimit is set to a number, and the maxActivationLimitBehavior is set to "error". When more that the alloted items are activated the error is thrown.

But when the error occurs it should still report the changes it has made thus far, otherwise the subscribers are never informed of the changes, and they keep displaying stale data.

In this version the error is caught, then the event is emitted and then the error is re-thrown.

This only affected you if you used activateByPredicate, and maxActivationLimit was set to a number, and the maxActivationLimitBehavior was set to "error".

When the last item of an ActiveList was deactivated the direction was reset to a hard-coded "right" instead of being reset to what was configured in the config.direction.next.

This only affected you if you used a custom next direction instead of the default "right" and "left" and cleared the ActiveList.