SOLVED

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

%3CLINGO-SUB%20id%3D%22lingo-sub-152541%22%20slang%3D%22en-US%22%3EBest%20practice%20recommendation%20for%20where%20to%20locate%20SPFx%20ReactJS%20component%20code%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-152541%22%20slang%3D%22en-US%22%3E%3CP%3EHowdy%20Community!%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIn%20looking%20at%20various%20SPFx%20tutorials%2Fsamples%2C%20I've%20noticed%20different%20paradigms%20demonstrated%20for%20where%20to%20locate%20the%20ReactJS%20component%20code.%26nbsp%3B%20For%20example%2C%26nbsp%3B%3CA%20title%3D%22Patrick%20Rodgers'%20tutorial%20on%20transitioning%20to%26nbsp%3B%40pnp%2Fsp%20from%20sp-pnp-js%22%20href%3D%22https%3A%2F%2Fyoutu.be%2FoAZX2_DFVjY%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3EPatrick%20Rodgers'%20tutorial%20on%20transitioning%20to%26nbsp%3B%40pnp%2Fsp%20from%20sp-pnp-js%3C%2FA%3E%26nbsp%3Bvs%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2FSharePoint%2Fsp-dev-fx-webparts%2Ftree%2Fmaster%2Fsamples%2Freact-async-await-sp-pnp-js%2Fsrc%2Fwebparts%2FasyncAwaitPnPJs%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ea%20React%20sp-pnp-js%20web%20part%20included%20among%20the%20SPFx%20samples%3C%2FA%3E.%26nbsp%3B%20Both%20achieve%20a%20'Hello%20World'%20flavored%20SharePoint%20query%2C%20but%20using%20very%20different%20syntax.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EPatrick's%20example%20houses%20the%20pertinent%20code%20within%20the%20.ts%20file%2C%20and%20his%20project%20does%20not%20even%20appear%20to%20have%20a%20.tsx%20file%20or%20%2Fcomponents%20folder%20at%20all.%26nbsp%3B%20%3CSPAN%3EJos%C3%A9%20Quinto's%20sample%2C%20on%20the%20other%20hand%2C%26nbsp%3Butilizes%20the%26nbsp%3B%3C%2FSPAN%3EcomponentDidMount%20function%20within%20the%20.tsx%20file%20for%20the%20pertinent%20code.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%0A%3CDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%3CSPAN%3EAs%20a%20newcomer%20to%20the%20SPFx%20framework%2C%20I'd%20like%20to%20know%20whether%20one%20or%20the%20other%20is%20a%20preferred%20'best%20practice'%20-%20and%20why.%26nbsp%3B%20Or%20is%20this%20just%20a%20case%20of%20personal%20developer%20preference%3F%26nbsp%3B%26nbsp%3B%3C%2FSPAN%3E%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%3CSPAN%3EThanks!%20%3A)%3C%2Fimg%3E%3C%2FSPAN%3E%3C%2FDIV%3E%0A%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-152541%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EDeveloper%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EPnP%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-152658%22%20slang%3D%22en-US%22%3ERe%3A%20Best%20practice%20recommendation%20for%20where%20to%20locate%20SPFx%20ReactJS%20component%20code%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-152658%22%20slang%3D%22en-US%22%3EI%20think%20it%20probably%20comes%20down%20to%20personal%20preference%2C%20experience%20with%20the%20Spfx%20technology%20stack%20etc.%3CBR%20%2F%3EWe%20have%20found%20the%20most%20effective%20development%20process%20to%20be%3A-%20%3CBR%20%2F%3E-%20develop%20React%2FRedux%20components%20in%20their%20own%20React%20specific%20library%20(using%20StoryBook%20to%20demo).%20Use%20mocked%20up%20services%20in%20this%20library%20to%20represent%20the%20data%20that%20will%20be%20accessed%20in%20SharePoint%3CBR%20%2F%3E-%20include%20that%20library%20in%20the%20Spfx%20TypeScript%20project%2C%20and%20reference%20the%20root%20React%2FRedux%20component%20in%20there%3CBR%20%2F%3E-%20develop%20the%20genuine%20services%20to%20interact%20with%20the%20data%20in%20the%20TypeScript%20project%20(using%20PnP%20JS%20core)%3CBR%20%2F%3E%3CBR%20%2F%3EWe%20find%20segregating%20the%20presentation%20components%20into%20a%20pure%20React%20library%20increases%20efficiency%2C%20because%20the%20development%20experience%20is%20more%20smooth.%20Spfx%20has%20been%20a%20big%20improvement%2C%20but%20%22gulp%20serve%22-ing%20everytime%20you%20want%20to%20see%20the%20result%20of%20a%20code%20change%20is%20nowhere%20near%20as%20rapid%20as%20using%20Storybook%20and%20having%20the%20page%20auto-update%20on%20every%20code%20save.%3CBR%20%2F%3E%3CBR%20%2F%3EBecause%20of%20this%20our%20end%20TypeScript%20project%20only%20has%20a%20single%20component%20in%20root%20the%20tsx%20file%20(which%20loads%20the%20root%20component%20of%20the%20React%20project)%2C%20but%20has%20a%20Services%20directory%20containing%20the%20services%20and%20their%20related%20interfaces.%3CBR%20%2F%3E%3CBR%20%2F%3EHope%20that%20makes%20(some)%20sense%3CBR%20%2F%3E%3CBR%20%2F%3ENigel%3C%2FLINGO-BODY%3E
Highlighted
New Contributor

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! :)
1 Reply
Highlighted
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