I just needed this widget for the neo.mjs calendar implementation.

Following the “Application worker being the main actor” paradigm, the list lives within the App web worker scope.

Content

1. Introduction
2. The code
3. Lists with many items or frequent changes
4. The status of the calendar implementation
5. Online demo
6. Final thoughts

1. Introduction

While the task sounds non trivial at first, it is actually very easy to implement using an UI framework.

Let us take a quick look at the result first:

2. The code

The first thing to do when creating a new component is to pick the best fitting base class. We want to create an enhanced list, so list.Base is the perfect fit. This base class gives us a selection model and keyboard navigation out of the box.

The calendar implementation is using one top level view model, so we can just bind the store from there. The list does not need its own view model.

We are overriding createItemContent() and create one checkbox field per record. After the field instance is created, we have the vdom property in place and can just return this one, plus an i tag for the edit icon.

It is important to also add a destroy() method, since we do want to destroy the checkbox field instances to avoid memory leaks in this case.

We add a change listener to each checkbox and update the related record field inside onCheckBoxChange() . The calendar week view listens to record changes and will automatically remove events for non active calendars.

I enhanced the selection.ListModel a bit, so that we can optionally directly use an onKeyDownEnter() method inside our view class.

Now we can walk through our checkbox list items using the arrow keys and once we hit “Enter”, we are simply toggling the checkbox checked config. This will trigger the change event and update our matching calendar record.

Mission accomplished.

3. Lists with many items or frequent changes

The calendars list is rather static, since it happens pretty rarely that a user will create new calendars or reload the list.

For more dynamic use cases, you do want to store the checkbox instances inside an items array.

Then, when (re)loading the store, you would check if we already have a checkbox instance at the given index and if so call checkboxInstance.set() with the same values we used inside the create call (except for the module and listeners).

Yes, it is a design pattern to re-use JS instances as much as possible.

I created a ticket for enhancing the widget this way. Please add a comment in case you would like to see it happen:

[Quick Update] Already implemented this logic. You can compare the gist version inside this article with:
src/calendar/view/calendars/List.mjs

4. The status of the calendar implementation

Finishing the calendar is the main focus item of the v2.3 release.

We already have infinite scrolling in place for the week, month and year views. Drag and drop based move or resize OPs work very well.

The calendar is highly config driven, so you can customise it in a lot of ways. This also works at run time!

The next steps are:

1. Adding an edit form to add, edit or delete calendars
2. Enhancing the event edit form
3. Adding new events via drag and drop
4. Adding the day view
5. Making the calendar fully responsive (mobile)

Once done, the calendar is ready to use for your apps.

I can strongly recommend to dive into the calendar code base:

https://github.com/neomjs/neo/tree/dev/src/calendar

Even experienced Javascript developers can learn a lot here!

5. Online demo

Here is the online demo (Desktop only for now).

dist/production
Minified webpack based build without source maps:
neo.mjs/dist/production/examples/calendar/basic/index.html

development mode (Chromium or Safari Tech Preview only)
Running the real JS code as it is directly inside your browser, no source maps needed:
neo.mjs/examples/calendar/basic/index.html

Hint: Inspect the DOM. Non active views will get removed, but you can still change their state inside the settings menues. Changes will get applied to the virtual dom and a card activation will just re-mount existing JS instances.

Hint2: Inspect the sources inside your dev tools (works best in dev mode). All components live within the app worker scope.