Foreword, what is the Notes?
Sciter.Notes is a personal notes and documents manager with the following features:
- Stores documents in single place – local database. That database can be encrypted by your OS means .
- Allows to edit/view notes in HTML WYSIWYG editor, Markdown editor and HTML source view. Therefore it can be used as quick HTML<->Markdown convertor for your documents.
- Allows categorization of documents not just by folders (Book in Notes terms) but also Tags for parallel classifications schemas.
- Supports free form text lookup across all notes.
- Export/Share/Backup of all or selected notes as plain HTML files that can be viewed by a browser on any of your devices.
- Sciter.Notes does not send any data anywhere. No “telemetry” or anything like that. It does request though for last Notes version available once per day but that is it.
Porting Notes from SciterTIS to Sciter
TIS (TIScript) used in old Sciter is not supported anymore and so in order to evolve Sciter.Notes further I have decided to port Notes to new Sciter.
While porting I also wanted to accomplish the following tasks:
1. Verify Reactor feature completeness on relatively large project
Reactor is Sciter’s native mechanism that covers ReactJS and WebComponents use cases. It is quite simple and implemented by just two entities:
- native JSX support by QuickJS++ compiler. JSX expressions get compiled into VNode literals.
- native Element.patch(vnode) function that takes VNode literal and updates DOM.
- on top of that I’ve enabled existing DOM functions to accept VNodes too. For example standard Element.append was extended to support JSX expression directly:
To my surprise such simple mechanism allows to do UI without need of any other mechanism or framework. It covers all use cases of ReactJS, VueJS, Svelte and also use WebComponents alike componentization.
2. Verify Signals as a mechanism of intercomponent communication
Signals were introduced in PReact as “reactive primitives for managing application state”. Personally I like them significantly more than those cryptic hooks/effects of ReactJS and so I’ve added native implementation of Signals to Sciter. The only one task left is to battle test them.
Sciter.Notes uses 9 signals that various components (views) are subscribed to.
Signals are very convenient and quite flexible. But I’ve discovered that one feature is missed – ability to fire (activate) signal unconditionally. Therefore I’ve added
signal.send(value) function to original PReacts API. This allows subscribers to react on sequence of signals that have the same value. Consider this:
signals.noteChanged.send(thisNote); // notify observers
User may change current note by many ways: typing, adding tags, changing book, etc. On each such change interested observers shall react somehow. And
signal.send(value) allows to accomplish that.
Alternative to signals are plain DOM events but their sinking/bubbling propagation nature could be an overkill in some cases. In any case Sciter.Notes uses both notification mechanisms: signals for application state management and DOM events for communication inside low level components.
Sciter uses QuickJS engine that implements ES2020 spec. In order to support JSX and data persistence natively I have extended it to QuickJS++ – that’s the version used in Sciter.
By design Sciter is an embeddable engine. Most of the time is being used as an UI layer of native applications where core application logic is implemented in other that JS languages – C++, Go, Rust, etc.