Vue 2 Internal Features from the Ground Up

Q&A: Type-based API and Nested Objects

Evan You

Evan You

Creator of Vue.js
Vue 2 Internal Features from the Ground Up

Check out a free preview of the full Vue 2 Internal Features from the Ground Up course

The "Q&A: Type-based API and Nested Objects" Lesson is part of the full, Vue 2 Internal Features from the Ground Up course featured in this preview video. Here's what you'd learn in this lesson:

Evan takes questions from students about type-based API and nested objects.


Transcript from the "Q&A: Type-based API and Nested Objects" Lesson

>> Evan You: So, types your questions as, right about view class component and decorators. Yes, these are officially supported and recommended ways to use TS with view, but we are also planning some upgrades to the type system 2.5 which allows you to get appropriate type inference, even using the default through API, so by the, view class component will be strictly optional for TypeScript users.

But if you prefer a type based API, you should probably still use it.
>> Evan You: Next question is, do you have any hints on good practices, how to design complex store or having nested objects is a good idea? Or maybe having flat structure is better.
>> Evan You: There really isn't a apply everywhere rule for designing this.

We design and shipped the module feature for view x, to sort of help you divide your big store into very clear units that you can that recompose together. Having nested objects really isn't, I don't think there's any particular downside to it, but having a flat structure, I wouldn't necessarily say one is better than the other.

It really depends on your use case, what your data structure is, what you are dealing with. So I think this might be too generic to answer. And it's hard to discuss without concrete requirements of the app. In Redux, there's this common practice of so called normalizing your data, and by normalizing, it means it makes it flat, in that, when you have one type of entity that is referring to another, similar to columns, similar to tables in a relational database.

Instead of embedding another entity directly into a parent entity, you will store them in different collections and then reference each other using entity ID's. So, sort of may restore more a relation of database of some sorts, which I think is probably a good idea if your data model is particularly complex.

So, that I would actually think is a better way to organize things. If you can successfully model your data structure that way, than you should probably go for it.
>> Evan You: Question. What do you think of creating data files for specific states with specific Wi-Fi functions?
>> Evan You: Yeah, they seems totally fine to me.

This is in fact, very similar to how you would probably split different models into different files in Vuex, as well. I'm just speaking to the chat.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now