As a Java Developer who mainly focuses on backend development, I stumbled upon the horde of doing frontend work. A skill I’m not completely unfamiliar with, but I have to admit, keeping up with everything that happens in the frontend world is something I do lack.

In this blog, I will tell you about the process of my latest iteration in the world of Angular.

Starting with just creating an app is a simple task: update node/npm, create package.json, create the first few components, add a service for http calls, etc. But after a while it gets more difficult…​

Haunted woods of errors

While my work seems pretty okay, there seems to be one flaw: once the user leaves the "happy path", it is going off track of my designed flow…​ As a backend developer, I mainly create machine-to-machine interfaces, which means my errors should be descriptive but could also be technical. With a frontend, the user is not always that technical and is prone to human errors, which means you need to make sure the user is self-reliant. The first thing one should do is prevent users from inserting incorrect data.

For example: avoid free text input if possible or restrict/guide them in any certain ways to make the user experience less error-prone. And at least if (technical) errors occur, they should be more descriptive and clear in what is wrong. It should tell what is expected of the user and how they could solve them.

Unveiling spooky unfamiliar new concepts: Signals

During my absence from the frontend world, the frameworks have progressed, and things I knew back then have changed. One of the things that changed for me is the use of Angular Signals instead of the old way of state-management via RxJS. Initially, it was quite a change.

Here I was writing everything with RxJS, and luckily, a colleague of mine pointed me to this. So now I had to study a new concept, which got my blood pumping since I love to learn, and apply it directly. TLDR: Be aware of the new developments even if the old things still work.

A Flashlight in the Fog: my AI chat prompt strategy

Since I did not have an experienced frontend developer next to me to explain me everything, like Signals, I had to resort to other means to get some help. I’m not a fan of running AI Code assistants to always take my codebase as context, but I do like using an AI chat to pitch ideas or ask questions about stuff I don’t understand.

One downside to this is that continuing such chats for a long time gives the AI more and more context and uses it for its answers, which is something I didn’t always want. So I created a prompt which gave an initial context about what tools I use and how I wanted my answers described. Since there is a lot of documentation on Angular online to be found, I wanted to stick to the official docs, and in addition, I wanted it to focus on the exact angular version I used (v20). Giving this as an initial prompt for each chat, I noticed the answers I received got better than without it.

Conclusion

Frontend’s been fun so far, new approach on error-handling and the immediate visual feedback of what you build is quite motivating. Furthermore, getting to know the new stuff in Angular like Signals has been real interesting, and beware of outdated knowledge. And not least, toying around with creating a more trustworthy AI context really gave me a new tool to use in the future!

Happy Halloween!

Sources

shadow-left