Component Libraries - Lego-Blocking Canvas Apps ๐Ÿงฑ

Component Libraries - Lego-Blocking Canvas Apps ๐Ÿงฑ

Image Credit to Semevent -


5 min read

If there's one thing I hate doing, it's the same job twice.

Whether it's using an AutoHotKey Script to start my comments out in code, or waiting for all the washing up to pile up so I can tackle it in one go, and not waste hot water......... I'm a big fan of reusability. Build once, Deploy many.

If you've built a canvas app, and found yourself having to make a small tweak to many different screens on an element that is consistent across one or more screens. Then some or most of the elements in your app are probably a good candidate for a Component Library. ๐Ÿค”

They're great for components such as:

  • Headers

  • Loading Spinners ๐Ÿ’ซ

  • Toolbars ๐Ÿ› 

  • Forms ๐Ÿ“ƒ

  • Complex Labels

  • Pop-ups โ—

  • Or just building something completely custom and cool ๐Ÿ”ง๐Ÿ˜Ž

When we start talking about Ecosystem enablement, Component Libraries are an absolutely fundamental digital building block that can be utilised by your maker population to speed up build and delivery of solutions across your organisation. They require appropriate nurturing, promotion and governance to get the best out of them.

Your first port of call is to install the Creator Kit as this may already contain everything you and your makers need. However, if you need something more bespoke; continue ๐Ÿš—

If the creator kit isn't what you want, or you want to put your own touch on the basics, create a base Component Library with some basic components that align to your organisation branding standards that your makers can start using right away. They're dead easy to make (about as easy as a Canvas App) and they can save some time for your makers who can now focus on delivering their solution.

Just make sure the Makers know how to install these new components!

At ANS, we were faced with the challenge of building multiple custom pages for a Model-Driven App between multiple makers. It was really important that we built a consistent experience for the end users; but giving a Figma design to 3 makers and expecting them all to interpret it the same way was never going to be an efficient approach.

We chose to use a component library so that all the styling and functionality was pre-built, we could also be safe in the knowledge that supporting each others pages would be possible, as we understood how the components of each page worked.

Ultimately this led to new custom pages being laid out in sub-1 minute time frames and let the makers focus on code and logic. We kept the experience consistent across all these pages and could make centralised changes to the component library to speed up with updating every page.

Here are some tips for building a component library:

Accessibility doesn't go away

You MUST continue to incorporate Tab Indexing, Tooltips and accessibility labels just like any Canvas App or Custom Page. Components will be read in Z-Formation by a screen reader (That is, Left to Right, Top to Bottom), see a short demo below on how this looks with Microsoft Narrator. Get those yellow triangles taken care of โš ๐Ÿ”จ

Remember, Responsive Design

Your components could be used in Custom Pages, Phone App or Tablet App. Remember to consider either building fully responsive, or tailoring components for different form factors (i.e. Phone or Tablet).

Keep it (the components) simple!

Don't make one massive component, make lots of smaller components that can piece together. For example, make a header, toolbar and form, rather than an entire screen component that does all three.

Keep it (the code) simple!

Try to avoid using Variables or Collections within the components purely for outputting data. For example, if you need to output a table in a certain format; rather than saving to a collection and pushing that collection to an output, consider using the ForAll() or AddColumns() functions to structure the table output on-the-fly.

Keeping this in the output property helps other devs easily find how and where the output is compiled.

Guiding your Makers

Adding a "Read Me" input property can help your users understand how your component works and how to use it (i.e. putting data in, getting data out, how to make it do the thing). Make sure you comment this out so it doesn't actually do something! ๐Ÿ™€.

Avoid "Property Fatigue"

Adding lots of properties to a component can make it unmanageable and sometimes even daunting to use. Try to limit individual properties and group properties together as record inputs. A great idea from James Ryan.

Build your components with customisation in mind

Keep your components useful and relevant by making it easy to change the colour scheme, border thickness and even the padding. Consider making this a record input with a pre-defined schema to avoid "Property fatigue" on the component.

Components ultimately reside in the msapp file

This is important to remember, because changes MUST be imported into your app, updating the component library on it's own is not enough to apply changes. Importing a component from a component library adds it to your App, rather than referencing it from the component library.

You can implement Custom Connectors in Component Libraries

Ensure you manage the deployments of your Custom Connectors across environments, but yes, you can absolutely add Custom Connector functionality to a Component Library.

Next time

That's it for now! Next time I'll be exploring how the different behaviours work in Components and how you can build re-usable code!