From 8abf4923a4d71810a3a4156c2c1d80fe554cd0a4 Mon Sep 17 00:00:00 2001 From: Michal Vanko Date: Mon, 28 Feb 2022 12:51:07 +0100 Subject: [PATCH] Link articles correctly --- ...-02-28-error-handling-with-either-type.md} | 6 ++-- ...022-02-28-second-attempt-weekly-08-2022.md | 31 +++++++++++++++++++ 2 files changed, 34 insertions(+), 3 deletions(-) rename _posts/blog/{2022-02-28-semi-functional-error-handling.md => 2022-02-28-error-handling-with-either-type.md} (95%) create mode 100644 _posts/blog/2022-02-28-second-attempt-weekly-08-2022.md diff --git a/_posts/blog/2022-02-28-semi-functional-error-handling.md b/_posts/blog/2022-02-28-error-handling-with-either-type.md similarity index 95% rename from _posts/blog/2022-02-28-semi-functional-error-handling.md rename to _posts/blog/2022-02-28-error-handling-with-either-type.md index 6f12894..d4b2867 100644 --- a/_posts/blog/2022-02-28-semi-functional-error-handling.md +++ b/_posts/blog/2022-02-28-error-handling-with-either-type.md @@ -2,7 +2,7 @@ layout: blog title: Error handling with Either published: true -date: 2022-02-27T16:03:10.093Z +date: 2022-02-28T11:30:54.195Z tags: - Development - Guide @@ -17,7 +17,7 @@ It will run on a server with a possibility of migrating into serverless when we ## API design -As it is not a classic web server application I had to come up with slightly different error handling as we are used to. I've been trying to find a semi-functional API with all the good practices described in my [guide on error handling](https://michalvanko.dev/blog/2020-12-09-guide-on-error-handling). The main goal is to not let users be presented with internal information about errors. We want to show user-friendly messages instead. +As it is not a classic web server application I had to come up with slightly different error handling as we are used to. I've been trying to find a semi-functional API with all the good practices described in my [guide on error handling](/blog/2020-12-09-guide-on-error-handling). The main goal is to not let users be presented with internal information about errors. We want to show user-friendly messages instead. I call this API semi-functional as **I didn't want to use monads** and go 100% functional. We use simple asynchronous functions to handle interactions. The goal is to handle errors that are expected. Unexpected errors should still be thrown and caught by an _"Error boundary"_ around the whole app that will handle and log the error. @@ -66,7 +66,7 @@ export type Either = Promise< * Try to execute an async function and return a tuple of `[Error, ResultType]` * If the operation is successful error will be `null` * If the operation fails, the `errorHandler` runs with the exception that was thrown, Result is `undefined` - * It catches all errors that might happen in the passed async task. + * It catches all errors that might happen in the passed async task * It will not catch any errors that are thrown from the `errorHander` */ export function wrapWithErrorHandler< diff --git a/_posts/blog/2022-02-28-second-attempt-weekly-08-2022.md b/_posts/blog/2022-02-28-second-attempt-weekly-08-2022.md new file mode 100644 index 0000000..520ff57 --- /dev/null +++ b/_posts/blog/2022-02-28-second-attempt-weekly-08-2022.md @@ -0,0 +1,31 @@ +--- +layout: blog +title: "Second attempt @ Weekly #08-2022" +published: true +date: 2022-02-28T11:49:53.914Z +tags: + - News + - Weekly +notes: > + + I went for a solution very similar to how GitHub is doing it. I've created an `iframe` and set up communication over the `postMessage` API. I was pretty much just debugging when should I fire the rendering process and whatnot. I was not bothered by handling multiple diagrams and I knew that the solution grew on complexity very quickly. On the next day, I just thought of an even simpler solution. I decided to skip the whole `iframe` shenanigans and just import the `mermaid` library dynamically into the page when the article has any diagram. This way I don't have to create any special logic around creating tokens for each diagram and the performance is even better for the client as the parsing doesn't require rendering a whole HTML document in the `iframe`. +--- +When I started to write this weekly I've got so deeply into writing about the error handling use case that I basically just dedicated the whole article to it. So this will be my second attempt just to not break the tradition. + +## Error handling guide + +You can check out the new [article on error handling here](/blog/2022-02-28-error-handling-with-either-type). It is basically a practical continuation of the [first guide for error handling](https://michalvanko.dev/blog/2020-12-09-guide-on-error-handling) I've written a year ago. + +## Stream updates + +This week we have been discussing the [state of JS](https://2021.stateofjs.com/en-us/) on the Tuesday stream. It went very well and I didn't even manage to get through it to the end. I am planning to continue on the topic when I get back from vacation on the 15th of March. +I will prepare a few advertising materials (probably just a poster) and share them across social media as I want to run the stream officially. + +## Mermaid diagram parsing + +On the Thursday stream, I've not been able to find a guest to discuss any topics so I just went for coding the diagram support for mermaid diagrams in my posts. I wanted to make render diagrams on the backend. +I was very surprised that the mermaid is directly dependent on the browser to be able to render SVG. I had to rethink all over again how I would implement it. + +I haven't finished it, yet. So **prepare for a new article** where I will present the solution. I will stream it on [my twitch](https://www.twitch.tv/michalvankodev) so if you're interested, **please follow me there**. + +Let's keep it short. Thank you! \ No newline at end of file