@@caiovinicius7871 I was actually having some conversations with individuals this week about this topic. This is definitely something id love to cover!
Please create a complete e-commerce project(home page, category page with filter system, product page, cart page etc), with all features using firebase. Obviously based on vue 3. Hope to see you soon with this project.
Sigh! This video started promising but well.... yepp, that's what everyone says: "There are situations when using reactive instead of ref is a good choice". But nobody wants to show me these situations. So far, since I really don't think having to write .value is such a bad thing, I only see downsides of using reactive. I can't think of _any_ reason to use it at all and I can't think of or find an example where it actually does something that ref doesn't do.... :( This is very frustrating! I want to know why it exists! It can't be just to omit .value, can it??
@@JohnKomarnicki Every drawback you mentioned, like the limitation with primitive values and reassigning, are drawbacks to *reactive*, But I'm looking for drawbacks to *ref*, apart from having to write `.value`. My point is that I just don't understand why `reactive` exists, because saving these 6 characters can't be the reason. Or is that actually it? I feel like I am missing something here :/
Ref were actually created to address the limitations for reactive. Obviously things like having to append .value is tedious, but again, that’s a very opinionated discussion
@@JohnKomarnicki Okay, then let me re-phrase my question: Why do people use `reactive` if `ref` can do everything that `reactive` can do, plus more? Is it just to not have to write `.value` or is there something I am missing?
@@dasten123 Right on, this was exactly my frustration when researching the answer for this after the official docs left me confused. Unfortunately for people like us that can't accept doing things one way over another without fully understanding why, we'll just have to understand how each of those works under the hood and make our own conclusion. Or, it could actually just be to avoid typing ".value". Either way, it's very short-sighted of the official docs to not explain why they've provided us with two similar options. Proxies are used for reactive objects and getter/setters are used for refs. I've read in one article that reactive() tracks each property of the object separately whereas ref() tracks the entire object so anytime a single property is updated, all subscribed effects/updates (for all properties) are triggered. So, it could be a performance thing. I don't actually know if this is true though as I haven't got around to testing it or digging deeper into how it works under the hood.
You're stating a very important point here, often missed: "Reassigning objects is possbile with Ref." That means you can destructure an object into a reactive REF one and bulk in there the props with it's values. Also alows to add new ones!
Isn't the error you're getting at 11:35 because personTwo is defined as const? Would you still get that error if you define personTwo with let instead of const?
Год назад
yes it is, but you cannot reassign reactive property otherwise, you will not receive error, but it will not update
Firebase 9 is not difficult. I think you must 1st watch fireblog 6 hours video from Sir John Kommm... . That will surely help you to understand how firebase does work. Like how to use cloud functions. And he is using firebase 8.
@John Komarnicki you can infact reassign values of an object that was declared with reactive. `Object.assign(target, object)` will either add a nonexistent property or update the value of an existing property.
According to most of the documentation I read prior to creating this video, this was not the case. Maybe we are crossing the idea of reassigning. But In the example within the video, you can’t re assign a completely new object to that variable
@@JohnKomarnicki I think I see what you're saying. Setting an object declared with reactive as a completely new object no but you can add existing property with "obj. = value" or add it in during an "Object.assign(target, obj)".
@@JohnKomarnicki 👍. Yeah it took me a bit to figure out how to effectively update the object in mass instead of each property at a time and found somewhere that using Object.assign(target, obj) will update the matching properties in the target object with the values in the second or add them into the target if they don't currently exist. If you need to remove a property instead of updating the value you can use "delete obj.prop" to remove it from the object.
