Front-end - Daniel Salvagni

Yet another developer writing a rich text editor

Back in 2012, when I discovered the possibilities of having a rich text input by simply adding the contenteditable=true attribute to my element, I tried to build a full content editor. I didn’t know the purpose of it at that point in time, however, it was nice to dig into these new possibilities. I remember it was a simple editor, although you could drop files and images into it, and it would automatically upload the files and attach them to the editor area. Expand the image previews as well. Furthermore, it also embedded content from Youtube and other platforms. It was a lot of fun. It was a lot of o hacks and workarounds as well. Not any longer after that, I sent this idea to the cemetery of side projects.

Ideas shouldn’t be isolated

Long before this quarantine period, we all are living in, I’ve been thinking about having a passive income somehow. In the past years, every article that I wrote, every piece of code or full applications that I did as side projects, I shared for free. Every time I had these thoughts of monetizing the side-projects I’ve built, I’d be stuck questioning myself: Would someone be willing to pay for what I have to say? Would someone buy a single front-end component? As you already guessed, never got the answer.

The sweet road of building a custom date picker

Recently I had to replace a date picker component in an Angular application and I decided, along with my teammates, to go with a custom solution. The previous date picker we’ve been using was a component from ngx-bootstrap library, which is a great one.

The decision of building a custom one was taken mostly because we need mobile support, and we didn’t find a solution off-the-shelf that would fit our requirements. It wasn’t an easy decision, a calendar is always tricky to build. Although, on our side, there was a narrow range of use cases that would make it simpler than building a date picker for global usage.

AccessRole Guard for Angular apps

There’s always that moment when you need to implement authentication and authorization to an application and, besides intercepting and protecting requests, we also need to protect the application’s routes. Angular uses Route Guards through canActivate and or canLoad methods to decide whether a route or a child module should be available or not, and, it can use multiple conditions – or Guards – to decide that.

Building time it’s a disappointing issue on Angular development experience

I am not judging, although it might appear as I am. I already mentioned a couple of features that make me think Angular is a great choice for a web framework and I’m still decided to invest my time on it. However, I failed by not evaluating it more deeply, to be fair. Anyway, we all have our flaws, don’t we?

Giving Angular another try

I have been playing with the latest Angular version for the last couple of weeks and I’m enjoying it. The last time I touched Angular 2+ was in 2016 on an Ionic mobile project and before that, only had experienced working with the now called AngularJS. The current version (7) looks great!