We developers are used to rant about Dynamics CRM web UI since many years. And we were always unhappy and disappointed:
- In 2011 we desperately fought for official Firefox and Chrome support
- In 2013 the new “Windows 8 like” layout was finally available for all browsers, but was equally slow on each one of them
- In 2015 Turbo forms were quite impressive except the lack of mobile support
- When Unified Client Interface (UCI) had arrived, we were eager to be able to write our own components based on it
- And now when PowerApps Component Framework (PCF) is finally here we need to ask ourselves a serious question: do we still have reasons to rant about Dynamics web UI?
And the answer is — you won’t be disappointed! There are plenty of topics that could be addressed in this area, hence this blog post.
But let’s start from the beginning
Hearing all this buzz about PCF we, here at CRM–Konsulterna, were thrilled to try to implement our own control. You can find it at:
It elaborates somewhat basic idea, which mimics many other controls over https://pcf.gallery/ — it takes a value and validates it. It might sound too simple for the real-life test, but here is one thing to remember — these values are European Union VAT numbers. And that means:
- We need to validate, not just format, but actual existence of the number in regulator’s database
- We need to support various formats that different state members are using
- We still need to remain user friendly, but input masking is a must
So. If you also had a similar idea, but failed to implement it from the first try, you too were probably captured by one of many issues that we have experienced along the way. But today we will be honest, unlike all these articles that climes that anyone could easily create PCF component on its own.
No. Not everyone.
The tools you need
It’s so complex and not straightforward so you might want to install XrmToolBox with specific plugin: https://danishnaglekar.wordpress.com/2019/10/07/pcf-custom-control-builder/. It will make your development experience at least bearable.
Some might not agree with us, but…
It would be much better if developers will follow functional approach in TypeScript instead of reusing old tricks from C# world. The code could be very compact and clean if concept of “closure” would be used more often.
Developers of third-party modules will not follow TypeScript recommended practices, instead they will be using approaches more suitable for each case. For example, sending functions as an argument to other functions — like C# delegates — not only requires some understanding in how to use from TypeScript, but also could be complex to satisfy type wise.
And since most obvious and easy to cover PCF controls are already created, we could expect that all future controls would require even more specific knowledge in very different areas.
So, what to do then?
As always — start a fight, figure out how to win it:
- Development tools are far from perfection, but we could expect that this situation will improve with time, we just need be patient;
- Since toolchain is improving and documentation and blog articles get outdated, treat component’s source code as single place of truth. Luckily there are more than 100 examples in http://pcf.gallery/ with links to respective GitHub pages.
Have you tried to write PCF component yourself? Where did you stumble? Or do you think it’s a great development experience and we just ranting for no reason here?