Meeting notes from the kickstart session (15/07/2021):

Use cases

• Ionic (w/ NGXS) [Nick]
  • Feature Module (race condition)
    • hydrate on state init
    • changes lost on state update
  • using example from async-storage-plugin for Ionic
  • state token was not correct
  • persisting only part of the data
  • transforming data
    • Serialiser/Deserialiser could not transform the whole state
    • synchronising parts of the state
  • Ionic recommended engine: SQLite plugin to Cordova [build to native], other options�:
    • localStorage —> LocalForage
    • indexedDb
• [Phillip]
  • Noob to the storage plugin
  • uses NGXS in multiple projects
  • wants to get involved
• PWA (no localStorage) [Ally]
  • use local-storage-plugin
  • async-storage-plugin looked stale
  • IndexedDb, WebSQL, SQLite etc �(PWA / Web workers / Service worker)
  • support PWA with offline storage
  • persisting two slices each in different engines
  • phonebook app
    • records go to indexedDb
    • user session data stored in SessionStorage

LocalForage

• abstraction for different kinds of storage
• tries to best choose which storage engine to use

Challenges:

• How does it impact the initial state
• Interaction with default state
  • using the default from State definition in the engine
  • when to update the state
• Migration between versions of an App
• Ionic: foreground vs background
• Define an extensible API using Engines, Migration, and Converters

Opportunities

• Bringing part Firestore Plugin as an engine

recording

Hi,

NW.js is also a cross-platform desktop application development ecosystem using web technologies similar to the Electron.
https://nwjs.io/

Under the initial requirement, I seeShould work with Electron?

I think the NW.js is also working as same as Electron still there are differences like features, the way we build the app etc.

Hence, could you please add theShould work with NW.js to the list?

Thank you very much

In the application I currently work on I had to useLocalForage to accomplish an auto-save functionality. The idea is that a user can play around with the application, create entities, link them together, and if he is happy with what has been created, can click the save button to persist everything in the server using a REST API.
I use thengxsOnInit hook to register an observer whose responsibility is to listen to specific actions.

Based on this experience, I would like to share my thoughts on the LocalForage/IndexDB field:

• Will you update the IndexDB on every dispatched action? An idea would be to have a setting to allow all, or to specify which actions are eligible to do so (via a decorator)
• Will the persistence be in a key-value pair?
• Can I persist more than one key in IndexDB? If so, what will be the key identifier?
• When will I flush the NGXS state from the IndexDB?
• I should have a way to destroy the created DB
• Since the persisted data will be there until we delete them, how about securing the persisted data?

@Carniatto & others. What is the plan to move forward with this?

Is there any update on whether NGXS will ever support an async storage engine? It's truly unfortunate that for applications relying on async libraries like SQLite, it's currently impossible to integrate them effectively with NGXS. This limitation feels like a significant hurdle, and it's disappointing that such a powerful state management library cannot support these use cases. I genuinely hope the team might reconsider addressing this, as it would greatly enhance NGXS's flexibility and usability for modern applications!