cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Destructure & consistent casing.

I would like to propose 2 ideas.

 

1.) Make the context object destructure compliant.

Today you cannot use destructure on the context object without getting an error. It would be great if the context is compliant with this es6 feature.

 

const { openForm } = context.navigation;

opentForm(); <<< Error

 

context.navigation.openForm(); <<< works 

 

2.) Make the context.navigation and Xrm.Navigation consistent with their casing. 

I don't understand why Xrm.Navigation and context.navigation, aren't they the same thing? I am going with the assumption of "d365 CE is powerapps". Making the casing consistent would make it easy for us to write DRY code instead of trying to figure out if the context is Xrm or powerapps context.

https://docs.microsoft.com/en-us/powerapps/developer/model-driven-apps/clientapi/reference/xrm-navig...
https://docs.microsoft.com/en-us/powerapps/developer/component-framework/reference/navigation

 

Status: New
Comments
Level: Powered On

About your second proposal, I think you are making a mistake. context.navigation and Xrm.Navigation are two totally different things. Don't forget that PCF is not only for Dynamics 365. You also can use them in canvas apps and maybe, one day, in other parts of the Microsoft ecosystem aswell.

Level: Powered On

@SirKato1337 

 

Yes I agree that powerApps is not specifically for D365. But, having different casings for essentially the same object makes it a lot more difficult to write DRY code. Especially when you want to create components that would work in both PCF and D365 (as a web resource).

 

The only difference between the 2 object methods are Xrm.Navigation.navigateTo and Xrm.Navigation methods are mostly promises (not a big deal).

 

I could probably write something like this, but it is just "eeewww" (and this assuming destructuring has been fixed).

const { navigation, Navigation } = Xrm || context,
nav = navigation || Navigation;

nav.openAlertDialog();

 

 

 

Level: Powered On

Can't you just always use context??

Level: Powered On

I could but that would not allow DRY code between powerApps and Xrm.

Who wants to juggle between Navigation and navigation (and I am already confused as to which belongs to what object)?

 

It wouldn't be as bad if destructuring works with unified Xrm.