Getting Started with State Management in Still.js

Question

As part of modern Web Application, State management cannot be put aside, as they’re not a simple aspect of complement but a very important piece which applications can not live without especially when it comes to modularized frontend.

See this video for hand-on practice: Youtube video

Follow the official documentation: Still.js Service Doc

Join the discord channel if you have further questions: Discord channel

Still.js provides different ways to handle State management (component/local state management video), therefore when it comes to Global State management, it provides with a built-in features called Services thereby making it possible to handle things in a Reactive way. Follow the bellow animated illustration on how it works behind the scenes:

Component 4 updates the store state, which is propagated to all subscribed components

What is a Service in Still.js****

This a a piece in the code placed in the most extreme layer in terms of architecture, thereby allowing external communication through means like API/HTTP. Services also had the ServiceEvent kind of variables that are declared as follow:

import { BaseService, ServiceEvent } from "../../@still/component/super/service/BaseService.js";

//This class will be places in the app/services/ folder
export class BiddingService extends BaseService {
    /** An array with a single country is being assigner */
    countryStore = new ServiceEvent(['Australia']);
}

In Still.js, all services must extend the BaseService class to be injectable into components. Reactive stores have to use the ServiceEvent type. After creating a service, it should be injected using @Inject, and components can then listen to specific data changes from stores (e.g. countryStore from above code):

import { ViewComponent } from "../../../@still/component/super/ViewComponent.js";
import { BiddingService } from '../../service/BiddingService.js';

export class BiddingDisplay extends ViewComponent {

    isPublic = true;

    /** 
     * @Inject
     * @Path services/
     * @type { BiddingService } */
     bService;

     stAfterInit() {
          this.bService.on('load', () => { //Check service readiness
               //Bellow, it Subscribe to ServiceEvent variable (countryStore)
               this.bService.countryStore.onChange(newValue => {
                     console.warn(`New country entered the Bid, follow the list: `, newValue);
               });
           });
      }
}

In the above example, we are specifying the path (folder) where the service is located, but this can be defined globally in the App level.
Still.js uses event-based reactive state management, where components subscribe via the onChange event. Any change to the state triggers notifications to all subscribers, regardless of where the change originated.

Retrieving value from the service is quite straightforward, as we only need to specify the store and put .value and the end as follow:

getCountryInTheBid() {
    const countryState = this.bService.countryStore.value;
    console.log(`----> Country Store before updating: `, countryState);
}

Updating a store is also a simple thing, in some cases we have to use some intermediate variables, this is the case of lists, follow the examples:

addMoreCountry() {

         /** Retrieve the state */
         const countryState = this.bService.countryStore.value;

        /** Updating the store and re-assigning it to the service */
        countryState.push(‘Madagascar’);
        this.bService.countryStore = countryState;
}

Conclusion

Do not forget to check the video tutrial;

Still.js uses event-based reactive state management that simplifies setup by requiring only services and ServiceEvent based stores. Components can inject these and implement their own logic, while any centralized logic can be handled in the main component.

Comments

Nice write up on Still.js state management, thanks for putting it together. I like how you explained services and ServiceEvent with examples, do you think this approach can scale well for very large apps or would it need extra patterns?

---

Hi James, definitely if scales very well for large apps, as the concept behind this approach is that the Global state is totally isolated from the rest of application, it does not get impacted by the components lifecycle and the components are also not impacted by it. Plus, this is totally another layer on the application architecture, which make the isolation seamless.