That's what we had it in part 1 of this series all over. We wanted to do something about that, so we came up with the Blis Digital Power Pages DevKit (or well, that's what we're calling it for now — mail us if you have a better name). In this second part of our blog series about Power Pages development, you'll learn how the DevKit works.
Constantly refreshing the browser to see changes, restarting servers, and emptying caches—Building Power Pages feels like going back 20 years as a developer. In the age of agile and DevOps, as developers, we are used to being able to do and adapt almost everything ourselves. This'shift left“In the case of Power Pages, we take the idea so far that the customer can make many adjustments himself and therefore does not always need us anymore.
But that only works if the development environment cooperates. So how is it possible that such powerful technology was sent into the world with such a poor development experience?
Well, complaining won't get you anywhere. So we got to work (or rather: did our Thijs Geurts) get to work. And thanks to his efforts, we found a way to significantly improve the Power Pages building process. That started with the use of Storybook.
How we use Storybook in Power Pages development
To improve the development experience, we are using Storybook in. Storybook is a development environment for React that can show the consequences of code changes in real time. This allows us to render our React code and see how our PCF components work without having to publish them to the Power Pages environment every time. Within Storybook, you can also work on isolated components, so that we can develop isolated React components that serve as building blocks for new PCF components.
Plus, with Storybook, you'll have your documentation in order right away. But the biggest advantage is that we don't have to deploy and refresh to see what the result of a code change is. For us as developers, working without Storybook is now almost unthinkable.
How does this work in practice?
But Storybook and Power Pages don't work together “out of the box”. This has to do with Dataverse: a Power Pages app is about data and therefore hardly represents anything if there is no data to show. So to see if it works, we need real (or at least realistic) data from the customer's Dataverse. Manually copying them (with JSON files) or generating dummy data is inconvenient, time-consuming, error-prone, and in some cases downright unsafe.
That's why we developed a “proxy” that makes it possible to connect to the Power Pages API from Storybook. This allows us to retrieve real-time data via an API and see how our components work with real data.
This API also adds security and authorization, allowing us to set roles and permissions. Users only get access to the data for which they are authorized. Not only is this crucial for the safety of development and test environments, it also gives us a realistic picture of how an app will work in practice for a real user. In addition, this way, we can ensure that everything we build is secure and compliant and, with this setup, we immediately establish a proven reference architecture for future development environments for ourselves and our customers.
Roadmap development toolkit
In the last part You can read all about automated testing of your Power Pages in our blog series. We'll also tell you more about our roadmap: what features are we still adding to the development toolkit.
Want to see the Power Pages DevKit in action? Just contact us and we'll schedule a demo.
.jpg)
