Piral is an open-source framework for microfrontends based on React. It brings everything to create amazing frontends using a scalable development approach.
The agenda should be almost identical in each post. We'll use
- Current progress to explain what has been done since the last post
- Future plans to explain what we are currently working on or have in our direct pipe
- Other thoughts to list some of the thoughts for future development
Please reach out to us in case of any feedback, ideas, or criticism. We'd love to improve!
We just released version 0.11! That's a big step forwards, especially for our goal to reach 1.0. We will now wait between 2 and 3 months before releasing 1.0.0.
There are two points why you should upgrade (or try) 0.11:
- With the new pilet schema we can explicitly run also on IE11, Safari, ... - no effort needed
- By introducing import maps for pilets you can create applications that are even more decoupled from the app shell - even dependencies can be shared without sharing
The first point we already discussed in the last what's new in Piral. If you want to leverage this new mechanism you'll need three things:
- Your app shell must be referencing
pira-corein 0.11 or later
- Your pilets must have been built using
piral-cli0.11 or later
- Your feed service must support the pilet schema
v1(if you use feed.piral.cloud then this works out of the box)
If any of these three conditions fail we'll fall back to the standard mode before 0.11 - so there is no risk of, e.g., building the pilets using
v1 as target schema.
The second point is super interesting and discussed in some detail on the documentation. We'll also create a video for this, soon. To keep this one short and practical: Import maps allow you to specify dependencies that are lazy loaded and can be shared with other pilets. The sharing of a dependency (A) is implicit and demands two things:
- The other pilet also declares import maps with the same dependency (A)
- The dependency (A) is used with exactly the same version
The mechanism works because the dependencies are always included in the pilet. So if pilet 1 and pilet 2 both use import maps with the same dependencies it will not matter if both, one (which one?), or none is loaded. The mechanism always works, because it does not assume anything about other pilets.
As a key indicator we use the hash of the dependency. Thus, version updates of dependencies that do not change any line of code will still yield the same dependency. Such an update, however, is unlikely. While some people want to have a behavior that - in case of only patch-level updates - treats two versions of the same dependency as equal, we cannot offer it.
One of the reasons why we don't want to use the version as indicator is that it will cause more harm than good. While most packages work with semver, some don't. Some work with it, however, do underestimate the propagation of changes in their dependencies. Thus in general we don't want to rely on the version.
As already pointed out we are now in the waiting and refinement game for 1.0.0. In particular, this means:
- Improving the documentation
- Adding more tutorials (or videos, see next section)
- Improving the Piral Inspector
Additionally, we are also adding some new stuff.
- Adding an extension for VS Code
- Bringing in advanced support for Blazor
- Playing around with things: full server-side Piral
- Playing around with things: support for React Native
- Playing around with things: pluggable build/debug mode
Let's dive into these five new things in order.
We want to make it easier to control Piral from VS Code. Sure, you can do everything today using the command line and VS Code tasks. But we want to make it even simpler. Our vision is that you have a tooling that integrates well and does all that for you.
The tooling detects what (and if) Piral instances or pilets are available in the currently opened folder. If there are any then we'd show additional options incl. building, debugging, validating, and publishing.
For instance, debugging a pilet would already start the VS Code debugging process, too. That way source maps would be correctly referenced allowing breakpoints and full inspection without requiring any custom configuration.
We've been experimenting with Blazor (WebAssembly, or short WASM) for a while now. While there are parts that are quite hard to get correctly aligned in general we feel that we can offer a really cool and useful Blazor integration. Not only would that allow including pages rendered from Blazor in a full Piral / React app shell, but also using components from React (or any other framework for that matter) in Blazor.
Since this can be lazy loaded we see a lot of immediate benefits as compared to isolated, stand-alone Blazor WASM applications.
Under the hood, a Blazor pilet would be a standard pilet, but having a WASM file, a DLL, and a JSON as manifest. The pilet just calls the WASM using the JSON with the DLL.
One thing to add here is that the full setup (e.g., registration of pages) should be doable in C#.
At this point we "only" have a small tooling / utility library for SSR available. We actually want to have a full Piral SSR server solution out there, too, which should be capable of running (i.e., pre-rendering) a full Piral solution without much trouble.
Not much to write here. Piral is quite agnostic and only uses
react and things like the
react-router. Therefore, in theory it should be possible to use Piral in React Native, too. Right now this is all guesswork, but our intention is to play around with this a bit and see where we are going.
We don't know yet if we can officially support React Native. As a first step we'll try to build successfully in the React Native ecosystem. As a next step we would love to showcase what Piral could mean in React Native applications (e.g., a super nice way of allowing plugins).
Right now we don't have any plans to check out a cross-platform scenario where a Piral instance can be used on React Native out of the box. This is still fully left to the development team of the specific application.
Finally, we want to look more into alternative build systems. We already released a Piral CLI plugin to allow building pilets using Webpack. In the future we want to make the whole approach pluggable such that
- scaffolding does no longer require any build tooling and can be used / installed much faster
- any build tooling (e.g., via
piral-cli-parcel) can be installed
- if no build tooling is installed then
piral-cli-parcelwill be added
When the first build / debug is demanded we'll therefore need to install
piral-cli-parcel (or nothing, if that has been done already explicitly, e.g., via the
With 0.11 we've also released the tutorials as videos on YouTube. The feedback so far has been great!
You can start watching our videos here:
We've also started publishing other Piral related videos. For instance, here is the video for the Piral Inspector, which is our free browser extension available for all major browsers.
More videos are planned for the future!
Piral is marching forward in a great way. We've some very passionate and great users and our desire to create the best microfrontend architecture, framework, and ecosystem is as strong as ever.
With the up and coming 1.0.0 we are quite sure to offer a full package - especially concerning documentation, tutorials, ecosystem extensions, and available plugins.