Forum Discussion

Tracy Sterling's avatar
Tracy Sterling
Copper Contributor
Feb 05, 2018

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, Patrick Rodgers' tutorial on transitioning to @pnp/sp from sp-pnp-js vs a React sp-pnp-js web part included among the SPFx samples.  Both achieve a 'Hello World' flavored SharePoint query, but using very different syntax. 

 

Patrick's example houses the pertinent code within the .ts file, and his project does not even appear to have a .tsx file or /components folder at all.  José Quinto's sample, on the other hand, utilizes the componentDidMount function within the .tsx file for the pertinent code.  

 
As a newcomer to the SPFx framework, I'd like to know whether one or the other is a preferred 'best practice' - and why.  Or is this just a case of personal developer preference?  
 
Thanks! :-)
developer
PnP
  • Nigel Witherdin's avatar
    Nigel Witherdin
    Feb 06, 2018
    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
  • Nigel Witherdin's avatar
    Nigel Witherdin
    Iron Contributor
    Feb 06, 2018
    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

Resources