SharePoint Framework and MobX – WebPart example

We know how MobX can make managing state of our SPFx app easier and what are its fundamentals. So let’s see how to put all that knowledge into practice.

We’re going to focus on example from the first article. Just for the record:

A mockup of an example solution

After creating basic SPFx WebPart, we can install MobX. In our case, we can use npm – we need two packages:

• mobx
• mobx-react

And to make our lives easier – ready-to-use components from Office UI Fabric.

With MobX onboard, we can create our store class. We’re going to share some observables, so let’s create actions as well.

export class ExampleStore {
@observable public SelectedColor: string = '#f03333';
@observable public SelectedIcon: string = 'FavoriteStar';
@observable public SelectedItem: string = 'This is the first option';
 
@action.bound
public updateColor(value: string): void {
this.SelectedColor = value;
}
 
@action.bound
public updateIcon(value: string): void {
this.SelectedIcon = value;
}
 
@action.bound
public updateItem(value: string): void {
this.SelectedItem = value;
}
}

We have to make sure, that our components share the same instance of the store, so let’s create it in the main WebPart class and distribute it to the rest of elements.

export default class SpfxMobxExampleWebPart extends BaseClientSideWebPart<ispfxmobxexamplewebpartprops> {
private store: ExampleStore = new ExampleStore();</ispfxmobxexamplewebpartprops>
 
public render(): void {
const element: React.ReactElement<imaincontainerprops> = React.createElement(
MainContainer, { store: this.store });
ReactDom.render(element, this.domElement);
}
…
}

Useful tip for future. If few solutions or webparts are using MobX, they load it separately to the target site. The same situation happens when user add solution provided by another supplier. It can use MobX as well and every instance of MobX can interfere with other. We should always protect our solution against this type of issue. I recommend to use isolateGlobalState flag:

	configure({ isolateGlobalState: true });

You can learn more about it here.

It’s time for our component structure.

• Main Container
  • Top Label
  • Middle Container
    • Dropdown #1
    • Dropdown #2
  • Bottom Container
    • Left Column
      • Row #1
      • Row #2
      • Row #3
    • Right Column Image

We assumed that the row icon is connected with the top label. So let’s look at ‘click’ handler of the first one.

@autobind
private onClick(event): void {
this.props.store.updateItem(this.props.text);
}

And render of our main label.

<label classname="{styles.mainLabel}">{this.props.store.SelectedItem}</label>

Click on the icon changes store’s observable that is used by the top label. Yaay! How about some reactions?

Rows suppose to make influence on the image column on the right. Let’s say that selection of the item causes sending request to SharePoint list to get the picture source. It’s a great opportunity to use MobX reactions.

reaction(
() => this.props.store.SelectedItem,
async selectedItem => {
const imageSrc: string = await ListService.getImage(selectedItem);
this.props.store.updateImageSrc(imageSrc);
},
{ fireImmediately: true }
)

Our function reacts to the item changes – it triggers a service and updates the image source. You can learn more about reactions here.

So, finally, we end up with our MobX based WebPart.

Basic operations on our WebPart

To sum up our article series:

• MobX is a library that make state management of SPFx app easier – it helps you share data between components
• It was created with the intention to use it with React
• Main elements of MobX based SPFx solution could be:
  • the store class with observables, computed values and actions
  • observer classes
  • reactions