SPFx coding guidelines

%3CLINGO-SUB%20id%3D%22lingo-sub-145374%22%20slang%3D%22en-US%22%3ESPFx%20coding%20guidelines%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-145374%22%20slang%3D%22en-US%22%3E%3CP%3EMorning%20everyone%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWe%20are%20in%20the%20middle%20of%20process%20of%20preparing%20migration%20our%20logic%20from%20typicall%20react%20components%20(React%2C%20Typescript%20and%20so%20on)%20to%20SPFx%20components%20and%20we%20are%20trying%20to%20make%20them%20maintainable%20as%20much%20as%20possible.%20So%2C%20I%20have%20several%20questions%2C%20may%20be%20you%20can%20help%20me%20with%20them%3A%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3Ecode%20guidelines%20-%20you%20know%2C%20I've%20found%20several%20variants%20TSLint'%20rules%20for%20TS%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2FMicrosoft%2Ftslint-microsoft-contrib%2Fblob%2Freleases%2Frecommended_ruleset.js%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3EMS%20recommended%20ruleset%3C%2FA%3E%2C%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2FMicrosoft%2FTypeScript%2Fwiki%2FCoding-guidelines%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Egithub'%20TS%20project%20coding%20guidelines%3C%2FA%3E%26nbsp%3Band%20rules%20within%20SPFx%20project%20itself.%20Could%20you%26nbsp%3Bsuggest%20which%20variant%20are%20more%20useful%20in%20terms%20SPFx%20components%3F%3C%2FLI%3E%0A%3CLI%3Ecomponent%20structure%20-%20there%20are%20several%20variants%3A%20typical%20React%20component%20with%20state%20and%20props%20types%20(or%20interfaces%3F)%20within%20one%20file%20or%20SPFx%20'way'%20with%20interfaces%20and%20classes%20divided%20into%20several%20files.%26nbsp%3BDo%20you%20know%20what%20was%20the%20goal%20for%20such%26nbsp%3Bapproach%3F%20I%20mean%20SPFx...%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3EThank%20you!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-147114%22%20slang%3D%22en-US%22%3ERe%3A%20SPFx%20coding%20guidelines%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-147114%22%20slang%3D%22en-US%22%3ETSLint%20rules%20is%20really%20up%20to%20you%2C%20but%20I%20would%20stick%20to%20the%20ones%20that%20come%20with%20SPFx%20solutions%20instead%20of%20using%20the%20ones%20you%20mentioned.%3CBR%20%2F%3ETSLint%20config%20files%20are%20created%20inside%20the%20Config%20folder%20on%20SPFx%20solutions%2C%20so%20if%20you%20are%20using%20TSLint%20extension%20for%20VSCode%20it%20will%20not%20work%20by%20default.%20I%20have%20created%20a%20blog%20post%20with%20a%20simple%20workaround%20if%20you%20need%20this%20scenario%20to%20work%3A%20%3CA%20href%3D%22https%3A%2F%2Fjoelfmrodrigues.wordpress.com%2F2017%2F12%2F06%2Ftslint-spfx%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fjoelfmrodrigues.wordpress.com%2F2017%2F12%2F06%2Ftslint-spfx%2F%3C%2FA%3E%3CBR%20%2F%3E%3CBR%20%2F%3ERegarding%20component%20structure%2C%20it's%20again%20up%20to%20you.%20I%20personally%20prefer%20to%20have%20multiple%20files%20with%20small%20blocks%20of%20code%20than%20having%20a%20long%20file%20with%20multiple%20entities.%20I%20find%20it%20easier%20to%20maintain.%20%3CBR%20%2F%3EThere's%20really%20no%20right%20or%20wrong%20answer%20here.%20Give%20both%20a%20try%20and%20pick%20the%20one%20that%20you%20feel%20better%20with%20%3A)%3C%2Fimg%3E%3C%2FLINGO-BODY%3E
Highlighted
Frequent Visitor

Morning everyone,

 

We are in the middle of process of preparing migration our logic from typicall react components (React, Typescript and so on) to SPFx components and we are trying to make them maintainable as much as possible. So, I have several questions, may be you can help me with them:

  • code guidelines - you know, I've found several variants TSLint' rules for TS: MS recommended rulesetgithub' TS project coding guidelines and rules within SPFx project itself. Could you suggest which variant are more useful in terms SPFx components?
  • component structure - there are several variants: typical React component with state and props types (or interfaces?) within one file or SPFx 'way' with interfaces and classes divided into several files. Do you know what was the goal for such approach? I mean SPFx...

Thank you!

1 Reply
Highlighted
TSLint rules is really up to you, but I would stick to the ones that come with SPFx solutions instead of using the ones you mentioned.
TSLint config files are created inside the Config folder on SPFx solutions, so if you are using TSLint extension for VSCode it will not work by default. I have created a blog post with a simple workaround if you need this scenario to work: https://joelfmrodrigues.wordpress.com/2017/12/06/tslint-spfx/

Regarding component structure, it's again up to you. I personally prefer to have multiple files with small blocks of code than having a long file with multiple entities. I find it easier to maintain.
There's really no right or wrong answer here. Give both a try and pick the one that you feel better with :)