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

Question

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

Answer 1

Both tutorials have tend to teach different things.

1. The first tutorial creates hello world web-part. What you will get to introduced are SPFX web-part structure, .ts files are typescript files which are similar to .cs files in C#. The author also introduced the recommended pnp js library( replacement for rest API's).

Summary: Introduction to Typescript, pnp js , If you are interested in learning typescript start here

2. The second tutorial uses .tsx files which are .jsx files under the hood. This part introduces you with React js, which is a JavaScript front end framework. React takes Component approach for building views of a web based application. Start here with react, if you are interested in developing spfx web-parts using React as the front end framework. Though you are free to choose any other framework like Angular, Backbone, etc as well.

Answer 2

For others that are looking, I really liked this guy's response from the community convo I started.

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.