Forum Discussion
Solved
Best practice recommendation for where to locate SPFx ReactJS component code?
Howdy Community!
In looking at various SPFx tutorials/samples, I've noticed different paradigms demonstrated for where to locate the ReactJS component code. For example, https://youtu.be/oAZX2...
- I think it probably comes down to personal preference, experience with the Spfx technology stack etc.
We have found the most effective development process to be:-
- develop React/Redux components in their own React specific library (using StoryBook to demo). Use mocked up services in this library to represent the data that will be accessed in SharePoint
- include that library in the Spfx TypeScript project, and reference the root React/Redux component in there
- develop the genuine services to interact with the data in the TypeScript project (using PnP JS core)
We find segregating the presentation components into a pure React library increases efficiency, because the development experience is more smooth. Spfx has been a big improvement, but "gulp serve"-ing everytime you want to see the result of a code change is nowhere near as rapid as using Storybook and having the page auto-update on every code save.
Because of this our end TypeScript project only has a single component in root the tsx file (which loads the root component of the React project), but has a Services directory containing the services and their related interfaces.
Hope that makes (some) sense
Nigel
I think it probably comes down to personal preference, experience with the Spfx technology stack etc.
We have found the most effective development process to be:-
- develop React/Redux components in their own React specific library (using StoryBook to demo). Use mocked up services in this library to represent the data that will be accessed in SharePoint
- include that library in the Spfx TypeScript project, and reference the root React/Redux component in there
- develop the genuine services to interact with the data in the TypeScript project (using PnP JS core)
We find segregating the presentation components into a pure React library increases efficiency, because the development experience is more smooth. Spfx has been a big improvement, but "gulp serve"-ing everytime you want to see the result of a code change is nowhere near as rapid as using Storybook and having the page auto-update on every code save.
Because of this our end TypeScript project only has a single component in root the tsx file (which loads the root component of the React project), but has a Services directory containing the services and their related interfaces.
Hope that makes (some) sense
Nigel
We have found the most effective development process to be:-
- develop React/Redux components in their own React specific library (using StoryBook to demo). Use mocked up services in this library to represent the data that will be accessed in SharePoint
- include that library in the Spfx TypeScript project, and reference the root React/Redux component in there
- develop the genuine services to interact with the data in the TypeScript project (using PnP JS core)
We find segregating the presentation components into a pure React library increases efficiency, because the development experience is more smooth. Spfx has been a big improvement, but "gulp serve"-ing everytime you want to see the result of a code change is nowhere near as rapid as using Storybook and having the page auto-update on every code save.
Because of this our end TypeScript project only has a single component in root the tsx file (which loads the root component of the React project), but has a Services directory containing the services and their related interfaces.
Hope that makes (some) sense
Nigel