Implementing Flux architecture in SPFx
Development SharePointJavascript development has become very complex with the vast array of technology available and increasingly demanding requirements. Creating solutions in Microsoft’s SharePoint Framework is no exception.
SharePoint Framework (SPFx) pretty much allows us to build powerful and user-friendly web parts and extensions using familiar technologies including TypeScript, NodeJS and SCSS. The Yeoman generator developed by Microsoft is a great starting point for the development of SPFx client-side solutions.
However, there are times when we need to extend the framework to meet complicated functional requirements that are not available out-of-the-box. One such technology is a way of managing a persistent solution state using something like Facebook’s Flux architecture.
In this article, I’m going to give you a rundown on how you can implement this architecture using React Redux in SPFx. Conveniently SPFx solutions can be scaffolded with React included using the handy dandy Yeoman generator. To speed things up, I won’t be going into the details of creating a new SPFx project using the Yeoman generator and the fundamentals of Redux.
Installing your dependencies
- Start a new SPFx project using the Yeoman generator with React.
- Choose not to install the dependencies immediately because additional dependencies that are not available by default are required.
- Add the following to your
package.json
file. - Run
npm install
and this will install the dependencies to get you started.
Wiring things up
The serious steps begin here. I have structured by solution based on what I think is best practice and a tidy way to start a React Redux project. You may follow any structure that suits your practices but the steps are still applicable.
There are five components that you will need to look at in wiring up your solution. These are:
1. Actions
The logic that processes data and sends the response to your store. This is where you transform your parameters and/or state for use in your app. You may request data from an API or simply process data such as a Date object in the state into a friendlier format.
2. Reducers
This is where you specify the responses to the actions you have dispatched. Remember not to mutate your action properties or state here. The logic to do so should stay in your actions.
3. Store
Configuration for your store where you combine your reducers and apply any middleware that you require. In this simple example I only have one store and a single middleware which is thunk.
4. Container
This is where you set your store configuration as defined in ConfigureStore.ts and bring everything together – essentially placing your solution on screen.
5. Component
The React component of your solution. This is where it can get tricky if you are unfamiliar with Redux because of the use of connect
to export the component.
This is because connect is a higher order component that creates an instance of your component described by your class and maps the persistent state and dispatch properties to your component’s properties.
In this SPFx solution, the mapped states and dispatch properties need to be explicitly declared in your class or the persistent state and dispatch properties won’t work. You can see this in the snippet above where I have merged all the class properties with the dispatch properties and state properties as defined in the actions and reducer respectively.
This means that you do not have to have add them to your component properties and any new component you connect to the Redux store.
Once all this is wired up, you’re ready to utilise the power of Redux in your solution.