Unanswered

PCF components: getting properties of context object, runtime vs interface

(0) Share

Report

Posted on by marchello

Hi,

What is the rule of thumb when I want to use some property of the context object that technically should not be there (it is missing from the typescript typings) but it is present in the runtime object?

It is never safe?

How about getting the url of the client?

From what I gathered:

officially it is not supported, since it is missing from the typescript typings
there is a context.page.getClientUrl method at runtime
should I just use window.location.href and then slice it with javascript?

My use case for getting the client url: I cannot use the built-in webAPI because I want to attach additional headers to the request, like duplicate detection or paging or formatted values, etc...

What about other webAPI methods, like execute/executeMultiple?

I have found blog posts (https://www.oliverflint.co.uk/2020/06/11/PCF-WebApi-execute/) from 2 years ago where this property was already present. 2 years maybe enough time to consider it safe? I don't know...

Our app heavily relies on calling API-s through execute/executeMultiple.
Should we not consider to upgrade to PCF components until these officially hit the documentation?

Categories:

Power Apps Pro Dev & ISV

I have the same question (0)

All responses (14)

Answers (0)

Diana Birkelbach 3,072 Most Valuable Professional on at

Like (0)

Report

Hi @marchello ,

My short answer is... "it depends". 🙂

A few thoughts on this...

Usually, what's not documented, is not supported. Sometimes is still a gap between what's documented and the TypeScript definitions: that's the point I consider safe to use, because it will most probably come in the near future.

But I use also some undocumented functionality, and the "execute" method is one I use a lot. It's not 100% safe, but it's the only way to call a Custom Action (Custom API), so I expect it to be supported sometime in the future (at least for online mode).

About getting the clientUrl: I'm not very sure if it's supposed to be supported. I understand the PCFs as controls on a form, view, custom page, but the controls shouldn't control a form or an app.

But maybe you don't need to the clientUrl. Since PCFs are only available for Online (so you don't need to care of OnPremise URL building), you could use a "root relative path": so something starting with a "/" , looking like this: "/api/data/v9.2/..."

Also it's worth to have a look to the context.webAPI first. The response you get there is already containing the formattedValues. As far I know you can build paging too. So maybe there are not so many cases you have to make your own requests.

Just keep in mind that the context.webAPI is working offline too. That's something would be harder to implement by your own (just in case you need it).

Just one more thought: the field PCFs are also able to have datasets properties too. So for some use cases, maybe you can use that datatset instead or using webAPI.

Hope this helps!

Was this reply helpful? Yes No
marchello 28 on at

Like (0)

Report

Hi @DianaBirkelbach,

Thanks for your reply (btw, I really like your blog!).
Yeah, I wasn't sure about formattedValues, but I included it anyway.
Paging is probably feasible too with $top and $skip, though currently we are using Prefer header with maxpage value and resolving links with @data.nextLink, but seems valid to do that as well.
One thing that is missing is the possibility to include MSCRM.SuppressDuplicateDetection header, but it is so niche in our codebase, that I could just probably get away without it.
So if I assume execute & executeMultiple is supported I can live with webAPI. Thanks for the tips.

As for datasets, that was the first thing I tried, because then I don't have to worry about paging, security and all the stuff. But unfortunately our architecture heavily relies on data that are stored in tables that are connected to the main entity as 1:N.
As far as I know you cannot configure a view where you wish to expand upon other entities that 1:N related to the main entity, you can only expand to N:1 lookup fields. But correct me if I'm wrong.

Thank you for your tips again 🙂

Regards,
marchello

Was this reply helpful? Yes No
Diana Birkelbach 3,072 Most Valuable Professional on at

Like (0)

Report

Hi @marchello ,

Thanks! 🙂 Happy if I can help!

The dataset PCF is supposed to provide you the data for tables. It could be for 1:N relationship, but you can go even further; like 1:N:N.

The biggest benefit is that you don't have to hard-code the requests, but let the maker/customozer choose views.
On top of that, you can add relationships programatically and add filters, change the page size of the page number.

So you do need to take care of paging, but you have methods for that.

I've actually talked about this last Saturday, to the Power Apps Developer Bootcamp.

Inspired from the content presented there, I intend to make some videos and blogs about the dataset PCF.

I've just published the first one: about how to make a datset PCF and use it for a subgrid: https://www.youtube.com/watch?v=4DSqi309OaA&list=PLdjxPZh8EJSfOzjQOy-I5WFIf6Kwm-MCv&index=1&ab_channel=DianaBirkelbachakaPCFLady

Stay tuned: some deeper use cases are still to come.

Hope it helps!

Was this reply helpful? Yes No
marchello 28 on at

Like (0)

Report

"It could be for 1:N relationship, but you can go even further; like 1:N:N"

How? I cannot configure a View to include data that is 1:N.
For example this is the Account view creator:
And when you click Add columns, this is what pops up:
I can only select entities in the records type field that are N:1 related.
How can you add 1:N relations to a view? (and consequently to a PCF dataset?)

Thanks for your reply.

Was this reply helpful? Yes No
Diana Birkelbach 3,072 Most Valuable Professional on at

Like (0)

Report

HI @marchello ,

As you mention, you cannot include 1:N inside a view. It depends on your use case.

If it's a dataset PCF used on a view (in the sitemap), and you need some more data from 1:N relationship, you can add a second dataset to the PCF. In the customizing you can bind it to a view. Using code you can filter it, if needed.

Another use-case could be if you are on a form. Then you use the dataset PCF for a subgrid. The data can be bound to a related view, but also to a not related one; in that case you filter the data inside your code. Like in this example: https://github.com/brasov2de/DatasetExample - the video to this will come soon).

Does it make sense? Not sure about your use case. If you have something more specific, please let me know about your use case.

Was this reply helpful? Yes No
marchello 28 on at

Like (0)

Report

@DianaBirkelbach
"In the customizing you can bind it to a view"
and
"The data can be bound to a related view"

To be honest these are the parts where I am lost, can't seem to figure out how to set these up.
The code is nice and pretty straightforward, but the setup...

Looking forward to your video, hope it clears things up for me.

Was this reply helpful? Yes No
cchannon 4,702 Moderator on at

Like (0)

Report

When @DianaBirkelbach talks about "binding" she's talking about the manifest of a PCF. A PCF can be associated to Datasets and to Parameters, and those can be Inputs, Outputs, or Bound (both input and output at the same time).

This is what it means to "bind" the control to a parameter or a dataset.

Was this reply helpful? Yes No
marchello 28 on at

Like (0)

Report

Well, our setup is a bit more complicated.
We have a subgrid on the quote entity where the (1:N) related quotedetail records are displayed. To each quotedetail record there is another (1:N) related quotedetailrelated entity.

Currently, I'm doing it manually through the webAPI like this:

api/data/v9.2/quotedetails?$expand=quotedetail_quotedetailrelated($select=someprop)&$filter=_quoteid_value eq GUID

Can this be translated to a PCF with dataset(s)?

Was this reply helpful? Yes No
Diana Birkelbach 3,072 Most Valuable Professional on at

Like (1)

Report

Hi @marchello ,

Then it's easier to explain,

It depends if you need "the quotedetails and the quotedetailrelated" (A) or only the quotedetailrelated (B).

For (A) you can use 2 datasets: for quotedetails and for quotedetailsrelated. The quotedetails you have the subgrid with "Only related records" (related to quote). For the second dataset you can choose a view for quoredetailsrelated, and using code inside the PCF you filter the data.

For (B) you need only one dataset for your PCF. But when you customize the subgrid, you don't choose "Only related records" but "All Record Types" and you can filter the data inside the PCF just like in the repository: https://github.com/brasov2de/DatasetExample/blob/simpledataset-extended-relationship/DatasetExample/index.ts#:~:text=inner%22%2C%20alias%3A%20%22Opportunity%22%7D)%3B-,context.parameters.dataset.linking.addLinkedEntity(%7B,context.parameters.dataset.refresh()%3B,-%7D

It's exactly what I'm preparing for the second YouTube video, and another blog. I hope I can explain better there.

But maybe this will unblock you until then.

Was this reply helpful? Yes No
marchello 28 on at

Like (0)

Report
Hi @DianaBirkelbach,

Okay, so I think I got it the A) scenario:
I define a data-set in the manifest, that is applied to the subgrid on quote. This will be responsible for loading the related quotedetail records.
I define a second data-set, that will load the quotedetailrelated records. Here all I can do is bind it to a view from the entity.
on initial loading, the 2nd data-set will load everything from quotedetailrelated simply because it has no way of knowing that it should only load records that are related for each quotedetail.
to overcome this, from the code I should do something like this:

// context.parameters.QuoteDetails is the first data-set // context.parameters.QuoteDetailRelated is the second data-set const conditions = context.parameters.QuoteDetails.sortedRecordIds.map(e => ({ attributeName: 'new_column', conditionOperator: 0, value: e })) // new_column is the lookup that connects QuoteDetailRelated with QuoteDetail context.parameters.QuoteDetailRelated.addColumn('new_column') context.parameters.QuoteDetailRelated.filtering.setFilter({ conditions, filterOperator: 1 }) context.parameters.QuoteDetailRelated.refresh()
So, the second data-set is aware of what is related to each quotedetail, this will fire a new request with the correct filters in place.

My observations (may or may not be correct, depending on the above is right or not):
you cannot bail out of the initial query. the one that has no knowledge of the relation between quotedetailrelated and quotedetail (maybe there is a way around that?)
you have to write code add filters to make it aware of the relations, thus it will result in an additional network request.
you have to write additional code to compose the two data-set together (of course that depends on how your component is consuming the data, but likely you should)

Where as with the one-liner (api/data/v9.2/quotedetails?$expand=quotedetail_quotedetailrelated($select=someprop)&$filter=_quoteid_value eq GUID😞
only one request
response is already grouped, so each quotedetail has an array property with its related quotedetailrelated records
no configuration in Dynamics
cons: no paging, no security, no offline, ...maybe others?

Thanks for your help and looking forward to your video 🙂

Regards,
marchello

Was this reply helpful? Yes No