Are we PCF yet?

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:

 https://github.com/crmkonsulterna/

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

Let’s start from building tools that needs to be installed on your PC before you start development. First you must have PowerApps Command Line Tool. Then full NodeJS harness — which is logical since all the result of our work needs to be compiled to JavaScript. And… Visual Studio 2017 or 2019 build pipeline. Since final packaging to CRM solution is done via command line using MSBUILD utility which is not globally available even if installed. And all these three tools do not integrate between each other seamlessly, causing a lot of confusion in friction points which requires some knowledge to resolve properly.

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…

Another strange thing here is why all the tools are “Windows only”. Even more, officially “Windows 10 only”. This cuts off vast majority of professional JavaScript / TypeScript developers who would prefer to use MacOS as their go-to platform. 

It would be much better if all this tooling would be implemented in pure JavaScript, as it is done for projects like React, Vue and many others. 

Next comes TypeScript which is the primary language in which PCF controls are written. Some might not agree with us, but check generated file for yourself, and you will see that the more we try to write TypeScript code in the way how we write C#, the more complex compiled JavaScript looks like. Often syntax sugar which TypeScript offers also leads to less efficient JavaScript thus stealing from system performance. 

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. 

But situation becomes even worse when existing JavaScript module needs to be used from TypeScript file. Even if this library was covered by DefinitelyTyped project, there is no guarantee that definitions are full, correct or up to date. There is a risk, that some “fine-tuning” needs to be provided, and that already requires some substantial TypeScript knowledge. 

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:

• Some experience in web development is still required to succeed: run through some articles what DOM is, how to handle JavaScript events, how to send HTTP request, how to work with CSS styles;
• 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.

And last but not least, check out our component: https://github.com/crmkonsulterna/EUVATOK it provides some useful examples: how to interact with third party JavaScript package, it’s called “inputmask”, how to call external services and how to deal with DOM events.

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?