Link articles correctly

_posts/blog/2022-02-28-error-handling-with-either-type.md

@@ -2,7 +2,7 @@
 layout: blog
 title: Error handling with Either<Type>
 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<ResultType, ErrorType extends Error> = 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<

_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!