Multiple Views in a PCF-Control

[TheTruePowerDev]

Hello!

I just started getting into PCF-Component Framework and reading through the documentation i realized that the scope of these controls are always very small, what i mean by that is that most of the controls (also in pcf gallery) only consist of one view and only have one little function.
Is there a reason for that? Are there any restrictions or isn't pcf the right framework for developing bigger controls with multiple views?

Thank you and best regards

[DianaBirkelbach]

Hi @TheTruePowerDev , 

The target of PCFs are to offer possibilities to provide UI elements for dataset and fields. They can be combined together through model-driven app (including Custom Pages), Canvas Apps and Portals. They integrate in the platform, and allows that way a better flexibility in the design. 

You can attach the dataset controls on a table level, on a view level or to a subgrid. The field PCFs can be combined on forms, canvas pages or custom pages too.
I understand CustomPages as a place where you can also combine all the PCFs. That means you can provide smaller blocks, which you can build together. Maybe is that a way to start to think about them: https://powerapps.microsoft.com/en-us/blog/custom-pages-for-converging-model-driven-apps-and-canvas-... together with LowCode possibilities.

The "unbound" PCF are not available yet.

At the end, it depends on requirement if you can work with the building blocks, or you need to make a bigger "application-like" PCF.

Hope this helps!

Kind regards,

Diana

[cchannon]

I would only add that if you truly want a 'big' PCF and don't want to assemble it from a collection of PCFs, there is nothing stopping you from doing so. In MD apps, you have access to the webapi and nothing constrains your PCF from taking up the whole screen, so nothing is there to stop you from building a PCF that interacts with data all over the system and presents it in some kind of custom dashboard-y thing.

That said, there would be some drawbacks; data inputs that aren't bound to the control don't call in to your updateview event, so there would be some functionality loss for any data that is gathered through webapi and not as a bound input. And, PCFs use annotationbase storage just like web resources, so a 'big' PCF will quickly outstrip the default attachment size limit and force you to increase that limit in settings. More importantly in my opinion is that the bigger your PCF gets, the more difficult it will become to maintain the code.

[TheTruePowerDev]

Hello @cchannon, thank you for your reply.
Regarding the data inputs, that aren't bound to the control not calling the updateview event:
By using a framework like REACT or Angular I could simply work around that problem, since the data binding wouldnt be managed by the default pcf updateview events - instead i could simply handle/bind those events via the inbuilt changedetection of those mentioned frameworks(react/angular) - or is this not considered best practice?

[cchannon]

Not really. What I mean is that any parameter  (whether data element or data set) that is Bound will automatically call your updateView function anytime there is a database commit to that data element or data set. But any input that is not bound is effectively static: you will get its value exactly as it was during init, no matter how many times updateView is called and no matter how many database commits may or may not have been made.

So, it doesn't matter that your react component is dynamic and handles state and props gracefully: if the param is not bound, you don't know when the value has changed, so you don't know to update your props so your control doesn't update.

Now, you could build your control in a way that you are making Retrieve or RetrieveMultiple calls effectively to keep the data accurate, but that is very situationally dependent and probably excessively chatty, so while possible, you're probably much better off relying on bound inputs everywhere you can.