Sp-dev-docs: Command Set onInit is called twice

Created on 15 Dec 2017  路  13Comments  路  Source: SharePoint/sp-dev-docs

Category

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

Why a command set is initialized twice (actually, recreated) - onInit called twice?
onInit is needed to perform some operations to initialize needed settings/parameters for the command set. Potentially (and in most cases) it will contain async requests.
If it's called twice then all the operations will be performed twice as well. It may lead to unnecessary doubling requests and even issues.

Steps to Reproduce

  • create simple command set
  • add console.log('onInit'); in onInit
  • look at the console - onInit is presented twice.
tracked bug-confirmed question

Most helpful comment

Still not solved, my extension (for the commandbar only and explicitly bound to a list) is initialized twice (two different .context.instanceIds).

All 13 comments

Thank you for the feedback.

This situation happens when the command set apply both to the command bar and the right-click menu.
The 2 command sets are initialized separately, as the lifecycles for the command bar and the right-click menu could be different.

@mpasarin no, it happens if I apply Command Set to Command Bar only.
?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/manifests.js&customActions={"93249694-c74c-40a3-96ad-eb54ccf4e627":{"location":"ClientSideExtension.ListViewCommandSet.CommandBar"}}

Please, reopen the issue.

@VesaJuvonen @mpasarin please, reopen the question

@AJIXuMuK you are totally right. While adding a CommandSet in both command bar and right-click menu will initialize them separately, when adding it just in the command bar the code gets executed twice regardless.

We will work to provide a solution to this situation. Thanks for catching it!

Thanks guys!

Still not solved, my extension (for the commandbar only and explicitly bound to a list) is initialized twice (two different .context.instanceIds).

I have an extension that that is deployed to "ClientSideExtension.ListViewCommandSet" (so both the command bar and the right-click menu). I get 3 context instances (yay me!). I'm guessing, one for each of these:
Added 1 custom actions to ContextMenu
Added 1 custom actions to RibbonDoc
Added 1 custom actions to RibbonLis

So as per the original question, how do we initialize our extensions without sending at least one unnecessary REST call? My button is likely to be used multiple times per page load so don't want to make the user wait each time, but at the same time, I don't want to make 3 identical calls for the same data when one should suffice.

Would it be a good idea to modify the context in "onExecute"? That way, the user would have to wait the first time they click on the button but subsequent uses will be quicker.

Hello, it looks like this still isn't solved?

In my opinion it should be prioritised, especially now the option exists to do tenant-wide deployments. If you have a number of extensions installed tenant-wide and they are associated with list types like document libraries / generic lists... the init code is being run twice every time any user views a document library or list in the tenant. It could degrade performance for large numbers of users?

Sure, the best solution is to keep init methods short / simple and to scope the extension as narrow as is possible but the framework should be doing the right thing and not running the init method twice.

Hi @AJIXuMuK - The underlying logic for the listview was changed a bunch recently, and we can't repro this issue any more with it.

@AJIXuMuK - can you please confirm the conclusion which we had on our side. Thx.

@VesaJuvonen Looks like the issue is solved. A breakpoint in my extension's onInit is triggered merely once (including when changing lists via navigation back and forth).

@VesaJuvonen - looks fine on my side as well.
Thanks!

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

Related issues

christianbueschi picture christianbueschi  路  3Comments

Ralms picture Ralms  路  3Comments

ken-harris picture ken-harris  路  3Comments

mikeparkie picture mikeparkie  路  3Comments

karishmaTCS picture karishmaTCS  路  3Comments