Unscheduled Detour

It’s another two weeks and 109 commits later, so it’s time for another Mattrbld devlog! Once again, the past 14 days have been busy ones, with work and Easter and all, but despite all that I thankfully still had some time to work on my project. Some things worked out just as planned, others…not so much, more on that in a bit.

Where We Left Off

In the last devlog, I wrote about how I’ve started using web workers to avoid having some heavier workloads block the main thread. I’ve also touched on the new project sidebar and the groundwork laid for project settings.

My plan for the last two weeks was to work on the “Users”-tab in those project settings and then move on to one of the core features: content collections and related fields and schemas, which—spoiler alert—I didn’t get to. I had my reasons, though… 😉

What’s Changed

User Settings

I was right on track with my plans in the first week before Easter. I kept fleshing out the “Users”-tab, which now allows for adding, editing, and deleting users in a project. This functionality is important since it allows the generation of “Invite Links”, which can be used to drastically simplify the Onboarding of project collaborators (they literally just have to click a link and authenticate if the project is not public before they can start editing content).

The actual invite-link functionality is not quite implemented yet, but every user added to a project has their own link, which can be copied with a single click. Other than that, the user management is a pretty standard affair. It allows setting the user’s name, email address and avatar for the project, as well as their role within it.

Detour No. 1: Custom Roles

Initially, Mattrbld was conceptualised with three core roles:

• Project Owners: the role with the most privileges, akin to an administrator

• Developers: the people with access to the project’s configuration and some advanced and technical features

• Content Editors: the most restrictive role, which allows users to create and edit content with confidence without fearing to break something and without needing any technical knowledge

Since these roles are only enforced on the client-side (Mattrbld being a fully client-side application), they don’t do much in the means of security (that’s left to the central Git-repository used for syncing). Instead, these roles change what the user is able to see and which areas of a project they have access to (without messing with the client-side JavaScript).

Due to this, I believed these three roles were enough, but while talking to my supervisor about a potential first test-run using Mattrbld in the field, I realised that in some cases having more control over what a user can see (and, to a lesser extent, do) with a finer granularity would be useful.

This issue seemed important enough to me that I went to implement it as part of the ongoing work on the “Users”-tab. With this change, it is now possible for Project Owners and Developers to define custom roles, which can then be assigned to users to control their privileges.

While these custom roles can have arbitrary names, they still have an “access-level” property, which controls their basic privileges within the project and is used as a fallback, should the custom role be removed at a later date. The value of this property is one of the three core roles.

For example, the custom role “Student” with an access level of “Content Editor” will not have the ability to see the project settings, like all other content editors, but could also be restricted from seeing and editing certain collections of content regular content editors can modify.

Detour No. 2: Syncing Changes

With the custom role functionality in place, I determined the “Users”-tab to be complete for the time being and was supposed to move along to planning the collection functionality right after Easter, but my curiosity got in my way.

Since the importing of projects worked so well, I was curious if I could also finally export, or rather sync, some changes back to the central repository. Perhaps I was also procrastinating some more theoretical work—but since syncing changes is very important for the project, I feel like I didn’t really lose anything by prioritising this for the rest of the week. Especially not since the final result provided me with a much needed dopamine hit.

Whenever a file within a project is changed, Mattrbld records this change to be able to show indicators in file lists, etc. This is done separately from the Git integration (which obviously is also able to detect which files have changed) for performance reasons. One of the areas where these changes show up is the “status-chip” right next to the name of a project in the sidebar.

Clicking that chip when it displays “Changes” is one of the two ways (the other being a dedicated button in the project dashboard) to start synchronising local changes with the remote Git repository. Mattrbld gives you full control of what changes to sync, though. It’s not an “all or nothing” situation and as such you can choose what changes to synchronise in a modal. Opening this modal also synchronises the locally recorded changes with the output of what Git thinks has changed, in case that ever gets out of sync (Git having the last say).

This experience of selecting changes and syncing them is deliberately similar to a git add followed by a git commit and a git push—because that’s what is (roughly) happening in the background. Still, the interface is kept abstract enough so that even a user with no idea about Git can use it to sync their changes.

A big challenge building this system was error handling. For example, what is supposed to happen when something goes wrong after staging and committing a change, but before pushing it? To address that, I’ve built in an error handler that is capable of resetting the state to what it was right before the attempt to sync was made, allowing it to fail gracefully and giving the user feedback accordingly.

One area that I have not tackled yet, however, are merge conflicts, which will need their own UI and solutions—but I’m saving that for a later date. The important thing for now is that with this new part of the UI, I was able to successfully sync changes with a remote Git repository, meaning that Mattrbld now works both ways! 🎉

Miscellaneous Changes

Onboarding

The Onboarding experience was slightly reworked to cause less duplicated code and eliminate some nasty bugs.

New Component: File / Folder Picker

I’ve added a new basic component, a file/folder picker that will come in handy when selecting pages to link to internally, or locations for files to be saved into during project set-up.

Better Sorting of Projects on the Home-View

Projects on the Home-view used to be sorted after their import-dates, which proved unreliable in some cases and also defied user expectations. Now each project locally keeps track of when it was last opened and is sorted accordingly so that the most recently edited project is now always listed first.

New Options in General Settings

The “General Settings”-tab that I introduced in the last devlog received some more sections for some quite essential project settings:

• Drafts: specify a location for all draft content that is pushed separately so it can be excluded from CI/CD pipelines

• Content Previews: specify settings for content previews so editors can see a preview of their changes before they are published

• Internationalisation: specify the languages the content is available in so fields which can be localised can offer the relevant UI for it

Don’t Mess with Names

And last but not least: I’ve decided against lower-casing the names of users and am instead displaying them as typed. This has the potential for some funkiness if people decide to spell their names funnily, but it is definitely easier than trying to properly capitalise names programmatically, since simply capitalising every first letter after a space is clearly not enough with Names like McMillar, D’Agostino, etc.

Up Next

Of course there were many more smaller tweaks and changes here and there, but that is mostly what I’ve been working on in the past two weeks. I’m happy and proud that the basic functionality is in and working and I’m excited to add the next piece to the puzzle: content collections and editing.

I will do my best to develop the data structure that was originally planned for last week in the next one so I can hopefully publish the next devlog properly through Mattrbld! Wouldn’t that be exciting?

Until then, thank you for reading and keeping up with my little project. As always, feel free to reach out over on Mastodon if you have any questions or comments, and I’m looking forward to reporting more progress in two weeks!