Sp-dev-docs: SPFx is not a framework agnostic

Created on 18 Jan 2019  路  10Comments  路  Source: SharePoint/sp-dev-docs

Category

  • [ ] Question
  • [ ] Typo
  • [x] Bug
  • [ ] Additional article idea

Expected or Desired Behavior

I am able to use any frameworks and toolset that I want.

Observed Behavior

Microsoft says:
It is framework-agnostic. You can use any JavaScript framework that you like: React, Handlebars, Knockout, Angular, and more.
But this is a lie.

  1. Typescript version. For some reason I am forced to use outdated 2.4.2 typescript version. This is not acceptable in 2019. But at least for this we have a workaround.
  2. React 16.3.2. I need to use React@latest for my new projects. SPFx states itself as a framework agnostic, but the truth is that it is not! If I will try to use desired version of React - workbench stops working.

Steps to Reproduce

Update React packages to the latest. Workbench stops working.

Submission Guidelines

For those who interested how to use latest typescript:

  1. install typescript as regular npm module: npm i -D typescript.
  2. add this code to the gulpfile.js:
build.tscCmd.mergeConfig({
  overridePackagePath: 'node_modules/typescript'
});
Needs spfx-general tooling answered by-design uservoice-request

Most helpful comment

  1. TypeScript isn't a framework... but the fact that SPFx is still relying on an old version of the TypeScript compiler is a fair "gripe"... but not a bug. If you want to push this, I'd suggest posting it as a feature request/enhancement on UserVoice: http://aka.ms/sp-dev-uservoice as that's the best vehicle.
  2. The term _framework agnostic_ in this context is commonly accepted as _[web] framework agnostic_ and relates to handlebars / react / angular / vue.js / knockout or other web frameworks. The statement is true... there's nothing that blocks you from using any web framework with SPFx... thus, it's not a "lie". Maybe you can take issue with the nuances of different versions, but SPFx does not block you from using different web frameworks.

    With that being said, some web frameworks have issues working within SharePoint... Angular & AngularJS are two that come to mind. This isn't a result of SPFx, it's a result of how that web framework is architected.

    The challenge you're running into is that SharePoint has a deployed version of Angular already added to the page since they are using it... it's a version that's been tested with all the existing React controls on the page & this was just updated to v16 recently.

    Because it's already on the page, it's not too surprising there are issues with conflicting versions on the page.

  3. A bug that you mention is something that does not work as designed by the supported stance. The two points in this issue aren't bugs... those are by design.

Thanks for the suggestion on the gulpfile.js tweak to use the latest version of TypeScript on your project... I tweaked your submission slightly to make the code more readable to others.

All 10 comments

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

  1. TypeScript isn't a framework... but the fact that SPFx is still relying on an old version of the TypeScript compiler is a fair "gripe"... but not a bug. If you want to push this, I'd suggest posting it as a feature request/enhancement on UserVoice: http://aka.ms/sp-dev-uservoice as that's the best vehicle.
  2. The term _framework agnostic_ in this context is commonly accepted as _[web] framework agnostic_ and relates to handlebars / react / angular / vue.js / knockout or other web frameworks. The statement is true... there's nothing that blocks you from using any web framework with SPFx... thus, it's not a "lie". Maybe you can take issue with the nuances of different versions, but SPFx does not block you from using different web frameworks.

    With that being said, some web frameworks have issues working within SharePoint... Angular & AngularJS are two that come to mind. This isn't a result of SPFx, it's a result of how that web framework is architected.

    The challenge you're running into is that SharePoint has a deployed version of Angular already added to the page since they are using it... it's a version that's been tested with all the existing React controls on the page & this was just updated to v16 recently.

    Because it's already on the page, it's not too surprising there are issues with conflicting versions on the page.

  3. A bug that you mention is something that does not work as designed by the supported stance. The two points in this issue aren't bugs... those are by design.

Thanks for the suggestion on the gulpfile.js tweak to use the latest version of TypeScript on your project... I tweaked your submission slightly to make the code more readable to others.

SPFx was updated to react v16 and it doesn't work with react 16.7. The issue is not because [email protected] has issues with SharePoint. The issue is that SPFx workbench rely on 1st level react dependency in node_modules. That means that developers are not allowed to use react with the version they need to. They have to use the version that SPFx workbench depends on.

Understood... I get the point... I was trying to explain that "web framework agnostic" doesn't always mean "with every single version possible, including one (v16.7) that's only a month old.

Have you tried updating your project to v16.7 and trying it out on a real SP page vs. the workbench?

No, unfortunately it doesn't work any way. Tested both - classic and modern pages.
Here is an error message:

[SPLoaderError.loadComponentError]:
*Failed to load component "3756b279-4b8d-4a73-99b7-77804bfef654" (MobxGridWebPart).
Original error: *
Manifest not found for component id "0d910c1c-13b9-4e1c-9aa4-b008c5e42d7d" and version "16.7.0".

INNERERROR:
*
Manifest not found for component id "0d910c1c-13b9-4e1c-9aa4-b008c5e42d7d" and version "16.7.0".
*
*CALLSTACK:
Error
at t [as constructor] (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-01-11.005/sp-pages-assembly_en-us_9e9449a10a42b2bfe9427253a0d86c6c.js:842:16049)
at new t (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-01-11.005/sp-pages-assembly_en-us_9e9449a10a42b2bfe9427253a0d86c6c.js:1886:21682)
at Function.e.buildErrorWithVerboseLog (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-01-11.005/sp-pages-assembly_en-us_9e9449a10a42b2bfe9427253a0d86c6c.js:1886:16484)
at Function.e.buildLoadComponentError (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-01-11.005/sp-pages-assembly_en-us_9e9449a10a42b2bfe9427253a0d86c6c.js:1886:12515)
at https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-01-11.005/sp-pages-assembly_en-us_9e9449a10a42b2bfe9427253a0d86c6c.js:1886:60523

This came up in the past... I can't recall the result of that discussion.

@patmill Is it possible to use a specific version of React, other than what's put on the page by SharePoint? Doesn't appear so... seems React is added by a specific SPFx component...

This came up in the early days of SPFx... can't recall if we determined it was possible to have two versions of React on the page.

I believe there is some black magic you can use to override the build in logic to reference the SPFX-manifest'ed version of react. I'm trying to track down someone who knows, and will respond.

I鈥檝e gotten different versions of React to work before by bundling it in a separate npm module project with rollup. I wouldn鈥檛 recommend it though.

I think this issue has been addressed so I'm going to go ahead and close it. If you feel otherwise, we can always reopen if necessary.

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues

Was this page helpful?
0 / 5 - 0 ratings