Best practice recommendation for where to locate SPFx ReactJS component code?

[Tracy Sterling]

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! :)

[#2 · Accepted solution]

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