DEV Community: Julian Schäfer

# The difference between progressive and partial hydration

Julian Schäfer — Mon, 24 Oct 2022 19:08:18 +0000

TL;DR: Progressive Hydration is about the WHEN, Partial Hydration is about the WHAT

For some time I'm trying to understand the whole thing about rendering patterns. Hydration is a big part of it. The internet is full of articles and tutorials about hydration and how to implement it. But there are fewer about what it really is and how to distinguish between the different types of hydration.

This article won't go into depth because there is other great content out there. Some of the best was created by ryansolid. However, I would like to give a quick note to someone who is trying to understand the whole thing about hydration.

Hydration

Hydration is the process bringing a app which is rendered by the server into the same state as it was rendered by the client. This involves work to download javascript, attach eventlisteners to the correct DOM nodes and recover state on the client side. This work comes at cost. Bandwidth is needed to transfer the data within the javascript to your client. CPU time for parsing and running javascript. All of this may slow your app. In the worst case users needs to deal with the "uncanny valley" effect, where the app seems like it is ready, but hydration isn't finished yet, and therefore it's not yet interactive.

To mitigate this issues there are several approaches to optimize hydration. I would like to explain two of them.

Progressive hydration

The first is progressive hydration, which tries to reduce the amount of data which is sent to the client for bootstrapping your application. Instead of fully hydrating your app at once, only chunks of data are sent to the client and parts are hydrated. Those parts may be hydrated if a special event is triggered like clicking a button or if a component comes into the viewport. Your app is ~~building-up~~ hydrating up.

Partial hydration

In comparison, partial hydration uses knowledge about the structure of your application. You as a developer or perhaps a smart compiler, knows which part of your application is always static or requires javascript. This knowledge can be used to determine which parts of your application need to be hydrated.

Conclusion

If you look at it from an exaggerated point of view, you could take spacetime as an analogy. Progressive hydration is the WHEN, represented as time axis. Partial hydration is about WHAT part in your application should be hydrated. Its like describing somewhats position onto the space axis.

Please note, that I do not think getting much range with this post and it was a quick type. Therefore, some parts could be improved. If something needs to be corrected let me know in the comments :)

Vue - an appwide error notification system

Julian Schäfer — Fri, 22 Apr 2022 12:00:37 +0000

User notifications are important to communicate feedback to the user. They need to be meaningful and descriptive. Most of the time they are triggered by an action. These actions can have different origins like an user input or scheduled jobs and are placed all over the app.

In this post I want to show you our approach to implement an appwide error notification system within vue. The special thing is, that all notifications can be triggered above the whole app and are handled in one place.

To follow the steps have a look at the little demo.

The demo explained

As you can see, this simple vue app consists of two child components, Pizza.vue and Pasta.vue which acts as our "business" components. Next to them is the Notification.vue component, which is responsible to display error notifications. In real applications there would be many more "business" components or even page components, deeply nested in each other. All of them may need trigger an action and inform the user if something unexpected happen.

This demo demonstrates a common usecase, where a business action is triggered from a user by pressing a button. This action starts an API call which may fail. If so, the user needs feedback. In this example, the call always fails.

For simplicity a mocked API response is used. It has some additional information for the frontend, like an error code and optional data. The response is wrapped to a custom error called ApiError.

// api.js
const response = {  
  status: 500,  
  ok: false,  
  json: () =>  
      Promise.resolve({ errorCode: "INVALID_PIZZA_ID", errorData: "-1" })  
};

if (!response.ok) {  
  const msg = `${response.status}: Error fetching pizza with ids '${id}'.`;  
  const error = await response.json();  
  throw new ApiError(msg, error.errorCode, error.errorData);  
}

As a developer you need to decide how you want to handle this failing API request.

// Pizza.vue
try {
  await getPizza(-1);
} catch (e) {
   // show a user notification
   throw new UserNotificationError(e.message, e.errorCode, e.errorData);

   // do not show a user notification and do some other exception handling
   // throw e
}

Sometimes it is necessary to notify the user, but not always. Maybe its enough to do something else, like logging the error.

However, if you decided to notify the user, we need to transform our ApiError into an UserNotificationError. Its purpose is to separate the concerns between UI and API layer. Therefore, it wraps all of the data given in ApiError and bubbles up the component tree. If there is no need to notify the user, we simply could rethrow the ApiError or handle it otherwise.

`errorCaptured` lifecycle

The UserNotificationError will be catched in the upper most component App.vue within the errorCaptured lifecycle hook.

I did not know this hook, cause all of the lifecycle pictures you see in the vue docs, does not contain it. As a side note, keep an eye on the API docs!

errorCaptured(err) {  
 if (err instanceof UserNotificationError) {  
    this.error = { message: err.message };  
  }  
  return false;  
},

The docs itself says that this hook is "Called when an error propagating from a descendent component has been captured". Hence, our UserNotificationError will be catched aswell. If we want to display a notification, we only need to filter for this type or error and enrich our error data property inside App.vue with the information of UserNotificationError. As soon as the value changes, the watcher inside Notification.vue triggers and displays the notification.

Meaningful notification messages

Now we got a global notification system, so we might think we are done? Wrong! I would recommend one last step.

For now, we never used the error information of the API response. It could be possible that our API response message is not that detailed or does not support the languages our frontend supports. Therefore, it is recommended (see here or here) to use those error information and enrich client side messages with them.

In this example I used vue-i18n to localize the notification messages. To do so, we only need to use the errorCode as a key for our localized messages strings and pass the additional error data (like the id) as parameters.

const messages = {
  en: {
    message: {
      apiError: {
        INVALID_PIZZA_ID: "No Pizza with Id {id} could be found.",
        INVALID_PASTA_ID: "No Pasta with Id {id} could be found."
      }
    }
  }
};

errorCaptured(err) {  
 if (err instanceof UserNotificationError) {  
    this.error = {  
      message: this.$t(`message.apiError.${err.errorCode}`, {id: err.errorData})}; 
  }  
  return false;  
},

Conclusion

That's it. Now we have a simple error notification system where all notifications are handled in one place, the top-level component. Also, we didn't use the API error notification. Instead, we gave the frontend code the ability to use its most appropriate message texts and localize them.

This is my second article. I would like to welcome any
suggestions for improvement, feedback, or pointers to false claims.

Photo by Nong V on Unsplash

Explained: Passing props to data - Why is my data not changing?

Julian Schäfer — Fri, 18 Mar 2022 12:41:45 +0000

Today I found out something basic that I should have known for a long time. The value for a data-property, associated with a props-property, is only set when the component is initialized! Further changes to the prop will not be applied to the data-property.

An example

Lets assume we've got the following child component, which gets some name passed by its parent.

Child.vue:

export default {
  name: 'Child',
  props: {
    name: String,
  },
  data() {
    return {
      localName: this.name,
    };
  },
};

A parent component can simple pass a name to this component. The initial data value inside Child is set to name, which is defined inside parent.

Runtime types with pass-by-value

I have always thought that this connection localName: this.name is passed by reference. So if you change the prop, you also change the data each time. But this is wrong!

Rather, it is passed by value, which means the value of this.name is copied and applied to localName. Therefore, only the initial value of this.name is applied to localName during rendering time of the component. Further changes are ignored unless the component is re-rendered.

This applies to all normal props-types like String, Number, or Boolean.

`Array` and `Object` are different

This could be the end of the article. However, there exists an exception.

Arrays and objects are passed by reference. So it is actually possible to mutate nested properties of the array or the object. Even if it is possible, you should not do it. For more information have a look at the official docs.

Example

I've also made an interactive example which demonstrates the behaviour of changing props and how it affects its related data property..

Summary

Keep this in mind if you change data in your parent component and it does not affect the local state of your child component.

This is my first article, so I would like to welcome any suggestions for improvement, feedback, or pointers to false claims.

DEV Community: Julian Schäfer

# The difference between progressive and partial hydration

Hydration

Progressive hydration

Partial hydration

Conclusion

Vue - an appwide error notification system

The demo explained

errorCaptured lifecycle

Meaningful notification messages

Conclusion

Explained: Passing props to data - Why is my data not changing?

An example

Runtime types with pass-by-value

Array and Object are different

Example

Summary

`errorCaptured` lifecycle

`Array` and `Object` are different