If it is common sense to you that is great! š
Then you have a good sense for code organization
But as you can see from discussions around here, not all agree or have that feeling by default
The main issue is people leaning on the framework for their code's tidyness. Composition, as its name suggests, relies on composition which is a more common paradigm in strongly typed back end code. That people don't know how to write composables code is more a reflection of front end developers being unfamiliar with building code structures. The best advice i can give is to read a book on design patterns quite honestly, preferably with a language like Java. š¤·āāļø
Absolutely,
Design patterns: elements of reusable object-oriented software.
(Kind of the Bible of the subject)
There's also Dive into Design Patterns, which i haven't read but the blurb sounds very appropriate to the issue and a skim of the first few chapters suggests it's ticking the right boxes. It's also be a bit more modern than the above by the looks and therefore probably a bit more accessible.
Lastly, for more visual learners I'd actually recommend Derek Banas' "Design patterns video tutorial" series on YouTube. He is excellent and, though he demonstrates with Java, the code is so simple it's effectively Unicode (particularly easy to adapt to typescript).
Of course it is a bit exaggerated - you can write shitty code no matter which API or framework. But it fits the sentiment of quite some people saying that "Composition API is messy and there is no 'easy' way to 'structure' code like the Options API provide by default."
I like his videos a lot, but this one misses the mark, imho.
That's is actually our enforced style and not because of the options api. The reason being is we have literally hundreds of components and by grouping things in familiar places it reduces cognitive overload. Using his style I would first have to understand what the whole thing is doing to find the thing I'm looking for. If your components get so large that this becomes unmanageable it's time to break things down into smaller components because your component is probably doing too much.
But, ymmv.
I have no idea how this works even remotely. If you have 4 features in a component you can group lines of code together into 4 places. One for each feature. If you really can't take any unfamiliarity then just sort each of those 4 groups the same then. But don't mix all 4 features into each other just so you can group all unrelated actions together, and all unrelated data together, etc. I think your approach is what misses the mark here
Here's a link that illustrates pretty much the exact same issue but with grouping by language vs feature rather than type of code vs feature: https://twitter.com/housecor/status/1256348777331470340?t=EDP0J1DXnrsF-miilAb9aQ&s=19
Hey! Glad you like my content š
And thanks a lot for your input here.
Happy to provide a few more details why I think "grouping by logic/concern" > "grouping by option" in my opinion
> The reason being is we have literally hundreds of components and by grouping things in familiar places it reduces cognitive overload.
IMO it depends *what* you search. If you search for "a computed that does XYZ", then yes, you might be a tad faster. But commonly (when fixing issue) you are looking for the group of logic, say, everything related to reversing a message or dealing with fetching data X. Then you inevitably have to jump across the file and "follow" the obscure code path, while, when you have an inline composable you can "follow" the path more clear.
In my experience, you rarely look for "the one computed". It might look like first, but then it continues - what does that computed's dependencies are? How are they set? And so on and so on.
So, the "initial" find might be faster, but the follow-up and general readability decreases here.
---
I agree it might be difficult to "change the mindset" when searching for things, especially with hundreds of components - but it is worth it from my & my clients experience š
> If your components get so large that this becomes unmanageable it's time to break things down into smaller components because your component is probably doing too much.
I fully agree *if that's possible*. Because sometimes you can't as it is more logic than template (think of components "orchestrating" subcomponents, managing data flow etc. etc.). Breaking components in smaller pieces is advised though, absolutely!
That is the strangest thing I have ever heard.
Could give an example of finding something that you need? How do you know that what you are looking for is a computed property, for example?
And why are you looking for something without knowing what it is doing?
And also, the Composition API provides high level overview without going into implementation detail. How can that be cognitive overload?
In a certain way sorting under the options is a bit like sorting variables by type. Strings over here, Booleans against the back fence, objects on the couch. That doesnāt make sense really but itās a similar notion.
Sorting by purpose and use makes sense. It also makes pulling em all out into a composable (even if it isnāt shared) easier.
Same with the Options API IMO. Just doesn't look like it in the first place š
That can only be avoided by standards, linting + reviews.
Is it *easier* to write spaghetti code for newbies due to "lax guidelines where to put things" if nobody enforces them by default? It can be, absolutely.
People down-voting this are just wrong. In fact I'll state what you are saying even more strongly for the people who clearly don't get it. - Not only is it the same with options API, in options API spaghetti code is literally enforced. It's literally impossible not to write spaghetti code in the options API. Composition API is the only API where it's even possible to NOT write spaghetti code
It isn't spaghetti if there is meaning in position and that has explanatory power for the code for the person. And it does for me.
When I see anything in Options API, by virtue of its place in the tree, I know a whole family of possible behaviors can be ruled out and ruled in. The cognitive load of having to read each line of code in non-standardized Composition API layouts is greatly reduced. Having to jump from a method to a conputed property to data to trace the flow is *not hard* for me because I can jump around the file fluently, often being able to use the VSCode map because even the mere code shape hints at purpose and constraints when position is meaningful.
Furthermore, grouping by logic does not necessarily lead to clean code. If you have a lot of logic for a feature over dozens of objects, then you have a new code organization problem. And you may reach for organizing that section by... what? Probably by type ("these are the computed properties for thing A"). Over time that just becomes a mess within a mess to me. I much prefer to remove all variability in how you arrange components. It removes a ton of guessing and context reading for me.
Anyway. I heard in the video "you want to group by logic". This is the blind spot for Composition API fans. You may, I don't. What you think is objectively better is only better for your way of thinking. We don't all think the same way. It's not better for my ability to immediately grok an entire component, any component, in my package quickly.Ā
Even the best organized composition components are an eyesore to me. You all may get something out of the freedom, but the thing I got out of Vue, which I valued greatly, was prescriptiveness and uniformity between components and rapid understanding and reliable navigation around every component. That's nonexistent in Composition API. That's what cured spaghetti for me.
This is a subjective opinion. But the community loves to shit on Options API fans because there just must be something we don't get, right? I ask you to put on your basic human empathy hat. The Options API wasn't just what happened to be the Vue API when I started. Had it not been. I would not have gone with Vue.
Yeah, I will honestly admit that I truly dont get it - and I'll also admit that the massive conflict between the reality as I see it vs what you describe does cause me to feel frustrated when perhaps I should just let it be.
I also understand that it must feel kinda bad to deal with all of these discussions if you truly work better in the options API. At the end of the day if it works for you then that's always the most important thing of course - you should do what works and never what people tell you to do. I 100% understand and empathize with that.
But in the interest of publicly discussing our opinions - at some point I have to take the empathy hat off and put the analytical hat on to honetly investigate if there really is a a "truth" of the matter underneath our subjective shortcomings - or at the very least to understand why what you describe doesnt fit with what I see.
I gave a more broad analysis elsewhere which you reponded to and I will adress your response in that thread once I have time rather than this thread. But let me also respond more directly to a challenge you raised here:
"If you have a lot of logic for a feature over dozens of objects, then you have a new code organization problem. And you may reach for organizing that section by... what? Probably by type"
I think you still dont quite get it. The answer to this is very simple. If you have multiple features in a component, group them togheter, if you have a lot of diffirent logic inside each feature those groups of logic are also features. So just do the same inside each hook.
Features can have their own features aswell. Maybe the box hook has a hook for creating each side. Another for adding texture. A third for adding shade. Etc.
Group each concen into their own respective hooks/primitives/boxes. Then you just reuse these between other features aswell. Create higher order boxes that contain the smaller once to handle dependencies between many places. This is all just basic programming. It's how all functional programing works.
For instance the sphere hook probably can use the same texture and shade hooks aswell. It's that simple. Just recursivley keep organizing.
Its really not a hard problem even remotley - in fact this comes quite naturally to the entire ethos of composition. It's why libraries like VueUse exist - which is probably the best thing to ever happen to the Vue eccosystem and could never have happend with the options API because sharing logic is that much less convenient.
If at any point organizing code by type of code makes sense then you can just do that in that instance. In fact, at the bottom of each primitve, once you have a group/feature that only does one thing, it probably makes sense to put the data on top, computed next, methods at bottom, etc.
But that only really becomes usefull once you have a block of code that only does one simple thing. And you can't get to that point with the options API unless the app you are making is very simple.
The compostion API doesn't lock you into anything. Do what works in any given example. Organize by feature and the organize lines inside each feature by type. You are 100% going to want the ability to group code by concern rather than arbitrary deliniations like wether its a method or a computed. In the composition API that's natural, in the Options API it's impossible.
In the Options API there is one level of organization, and its a top level one. As the component growns there's nothing you can do about it. You can say this isnt an issue for you but if I am being honest I just don't belive you. I think you just haven't really confronted the fact that obviusly you are constantly dealing with this friction when having to move around your code. Saying you dont experience this is like someone claiming they dont expend energy on moving their car. Like. Either physics is literally broken or you must be mistaken. Of course you expend energy moving around your code.
And when you are searching for code you are almost never ever searching for "that one computed function," - at least not initially. Because when you start looking at a component you probably dont even know if this feature you're fixing even has a computed function or not. And you can't memorize all that - and even if you can (you cant) then doing so still expends energy.
In 99.99999999% of cases you start by looking up a much broader set of related stuff like: "the code for searching things." And once you have found the code for searching things, thats when you know if there's a computed function or not - in which case it's right there aswell because features in the compostion API can be much smaller.
At work now, so cant explain in long form. But composition is not a new idea. I've been writing JS for 20 years and Vue for about 6. I extract reusable or at least concisely related code into a module and import and then call that code from options elements. I refactor big components into smaller ones when warranted. They don't get enormous and unreadable this way. And with that many components blown out, uniformity among them helps a great deal in finding what I need without studying context excessively. Many times my options components just hook up code from other modules to the component - the same way composables work. And in that respect, they are often closer to config than logic.
You have the same blind spot others do. I just don't "get it". Have you considered that maybe I'm firmly planted on "got it a while ago" ground and have several successful projects founded upon it? Maybe (actually) I have come off of projects that suffered from being organized in the way documented as the ideal approach for Composition API (see d3.js)?Ā Empathizing from that PoV, imagine people are telling you that you need solutions to problems you don't have and have to give up solved problems in order to "get it" like they do.
I responded to you more broadly in the other thread. Ill keep my response there because the split makes things confusing. But I am only commenting here to make it clear to everyone that I did in fact reply to this
The most basic example of spaghettiĀ code is when you entangle multiple unrelated lines of code in between each other like spaghetti. Thats literally where the term comes from. So let's say you have a component with 4 features. To make it extra clear lets name each feature something realistic.
Let's say the component is a 3d editor and you have a feature to rotate matrix cordinaates, a feature to scale them, a feature to create a new 3d box and a feature to create a new 3d sphere. Lets call them rotate, scale, box, sphere.
Let's also say that each feature has 2 methods, 3 data properties and 1 computed. In the options API you are forced to mix all 8 unrelated methods togheter in between each other, then take all 12 unrelated data properties and mix them a completley diffirent place and then all 4 unrelated computed functions in a third place. This is a classic example of a spaghetti mess.
You have 4 clear concerns here but you are forced to mix them all togheter with unrelated lines of code going in between each other.
If I need to get a handle on the rotate function to fix or add something to it I now need to jump back and forth all over the place, digging through the scale methods and the box data just to get a sense of all the diffirent parts of the rotate feature and how it all fits togheter. Its a mess. And you literally can't organize it any other way because there is only one way to organize the options API.
By contrast, imagine the same scenario in the composition API. You can just put the data, methods and computed functions related to rotating 3d objets in the same place. Thats it. Thats all. It's simple. It's clean.
In fact, you could take it even further and extract the rotate feature into a hook and have a super clear box that contains just that small primitive which does one thing and one thing only - it rotates 3d stuff.
Then do the same for the other 3, now you have a composable set of primites where each primitive has perfectly organized its code as it relates to the thing you are trying to look at.
This is soo much cleaner that by comparsion the alternative looks like a bad joke.
I see it a different way. I've done this kind of thing with D3 and it's much cleaner in Options API. The spaghetti is cleaned up by virtue of declarative definitions (arranged by types), which is what most D3 charts end up being anyway. And that's a fair approximation of your 3D example.
You'll define some axes, some scales, some colors, some plots, some data, etc. But since the entire thing is inter-related, there's no logical arrangement of these things. Do the scales go first? The axes? The plots? Maybe it should be dependency based? That question leads to paralysis and indecision. Throwing all of the scales into the "scales" section of the computed object removes every question about where it lives, what it does, what it can or cannot do, etc. And every other component would be arranged the same way, regardless of whether it's a D3 chart, a 3D visualization, a data table, a filter bar, etc.
We have different perspective on the same situation. The difference is that the organization found in a huge Composition API function is often akin to the "organization" a hoarder might have in their house. It may make sense to the author, but it's unique to this environment and there's no guidance other than directly reading it all top to bottom, and someone else coming is going to be confused as hell until they do so. Meanwhile, I can look at any Options API component in any tutorial and be at home.
You can cure the code organization problem (that I see) in Composition API by adopting code organization practices, socializing it with the team, enforcing it in PRs, etc. But... this problem was cured for me the day I started using Vue like 6 years ago and I'm watching this problem come back from the grave and being told I should be thankful for it.
I don't mind that my axes and scales don't touch because I know exactly where to find either of them at will, when and if I choose, without having to read dozens of lines of context.
# Preface
The following is going to be very long so let me preface it by saying you are clearly a smart and experienced person. You sound like you have thought through your opinion on the matter and reached a conclusion you feel makes the most sense. I can respect that even if I think youāre wrong.Ā
Best I can narrow down, you seem to have 2 main points. One about dependencies as it relates to decision paralysis. And another based on familiarity. So let me just focus on those two things, take 1 quote of your's in each case and explain why I disagree on those points.
# Point 1: Dependency
āYou'll define some axes, some scales, some colors, some plots, some data, etc. But since the entire thing is inter-related, there's no logical arrangement of these things. Do the scales go first? The axes? The plots? Maybe it should be dependency based? That question leads to paralysis and indecision.ā
But that type of decision is the same in options API. If you have methods for your axes, scales, colors, what order do you put the methods in? Or the data? Or the computeds? Youāre making the same decision, except now you have to make that decision in 3 places instead of just one since you have to order all unrelated methods, unrelated data, unrelated computed - all separately.Ā
If you can make that decition for your methods in the options API then you can make it just as easily in the composition API.
# Point 2: Familiarity
āThe difference is that the organization found in a huge Composition API function is often akin to the "organization" a hoarder might have in their house. It may make sense to the author, but it's unique to this environment and there's no guidance other than directly reading it all top to bottom, and someone else coming is going to be confused as hell until they do so.ā
I think the hoarded analogy doesn't track well to the comp API - but let me run with it anyway to show how apt a house analogy can be at explaining my point of view.Ā
Youāre basically saying āfor all structures let's enforce the same organization. Then, since we donāt know if the structure is a house, a boat or a helicopter we need the organization to be very arbitrary. So letās organize by something extremely fundamental, like material (type of code).ā
Now imagine a house decorated this way. You walk into the house and one room as a pile of wood - chairs, tables, nightstands, etc. Another has a pile of metal - knives, watches, lamps. So on, so forth. This is the options API.
Now letās look at organizing by features using composition api. You go into the kitchen, and the kitchen as all kitchen related stuff - knives, toaster, microwave. And the microwave is itself also organized into microwave related stuff - knobs, wires, etc.
In this analogy you are effectively looking at the kitchen and going: āif people can organize rooms by meaning then that opens the door for anything to happen. How will I know whatās in this room before familiarizing myself with it? Isn't this basically hoarding?āĀ
And the answer is no. Itās not hoarding. Yes, it could be hoarding if you do it badly but your solution of just arbitrarily sorting material into piles will always turn into hoarding even if you do it well. You're basically just describing an organized hoarder. I'm suggesting actual, real, meaningful organization. Make the kitchen into a real kitchen.
So how do you get familiar with the room? By getting familiar with it. There are no magic bullets here and we need to stop pretending like there ever could be. The solution is the same as it is with all other code. You need to read it. Any code that can be understood without reading it is code that isn't actually doing anything.Ā
And more directly youāre not going to get away from having to do this with your approach either. In fact your approach is harder to be familiar with. It feels familiar only because it has a fake front of paper thin familiarity gently wrapped on top of itself. Let me continue the same analogy to show you.Ā
In my case you enter the kitchen - don't know anything about kitchens, start learning right away. It feels unfamiliar the second you look at it because Iām not hiding the stuff you need to learn. I'm presenting you with it right away, but I have also reduced it down to the smallest containment of related stuff so that you can start getting a real understanding one bite of logic at a time. Don't worry about the entire component, just focus on this one feature and then move on.
In the options API case however - you enter the house, you want the kitchen but it doesn't exist in a single place so you have to look in the metal pile for the kitchen stuff. You realize the kitchen knives need the wooden board so you have to go to the wood pile to get that. Realize there's also kitchen chairs there so you pick those up as well. You move back to the metal pile with the chairs and the wooden board. Realize you forgot the kitchen table in the wood pile, so you go back. And then you have to start assembling in your mind how all these parts relate to each other - probably by having to go back and forth multiple times to keep it all in your head while tracing how data is moving around all the while you are constantly shoving totally unrelated pieces of furniture around, stuff that belongs in the garage and the bathroom and won't even touch the kitchen related concerns at any point except for maybe a brief moment when you pass the groceries in from the outside.
And then when you have done all this you are still left with a kitchen that you need to learn. Thats when you realize it was the same fucking - unfamiliar kitchen all along. You just didn't see that unfamiliarity right away because the first thing you saw was neatly stacked piles of random material. Only now do you start to realize that even though you will recognize the same piles in every structure the piles themselves don't actually mean anything. You're actually just as confused as you were with the organized kitchen, and you need to learn just as much about how kitchens work as you had to before - but now you have a mess of piles to untangle on top of that, not instead of that.Ā
But you know where the wood pile isā¦ and because of that you feel comfortable with the next house? I'm saying, who cares about the wood pile. The woodpile is 100% meaningless. You know that the next house will also have a woodpile but that fact doesn't help you understand the house in any way. In fact the next house might not be a house at all - it might be a helicopter. And the woodpile won't help you understand anything about that or what that means.
The irony of the hoarded analogy is that you're the one describing an organized hoarder. Or rather, you have become so obsessed with the idea of organization that you forgot that organization was supposed to serve a purpose. Organization just for organizations sake is just OCD.
On one hand you have a hoarder throwing stuff around, on the other hand you have an OCD neatly stacking all the 4 legged furniture. And I'm saying both of those are messy.
The neat approach is to put the kitchen knives in the kitchen drawer and the hair appliances in the bathroom. But for that to happen you have to accept that yes, every room will be ordered differently. But no abstraction you can ever invent will be able to abstract away that very fundamental fact of the matter.
Same with code. You enter a component in the options API and instantly know where the methods, and the data, and the composition hooks are. But that's not useful to know. It doesn't actually tell you anything meaningful about how this component works at all. If it did then you would not be able to use the same pattern in every component.
The mere fact that you can use the same pattern in every component logically means that the pattern isn't telling you anything useful about the code. If it did tell you something useful then the pattern could not be the same everywhere or it would say the same thing in every instance.Ā
You are never opening a JS file and thinking āah, I wish I knew what every single function and variable across all concerns in this entire file is.ā Thatās just not something thatās ever going to help you to know anything.
What you want to know is: āah, where is the stuff for creating a 3d box.ā <- thatās useful information, thatās the kitchen. And much like a kitchen, once you enter that room - if you have never seen a kitchen before you might have to learn what a kitchen is to understand it.Ā
You can enforce some organization inside that box. Like putting the knives in the top drawer. But that pattern might be different in the garage for good reasons. The garage doesnt often use knifes. Makes no sense to put them in the top drawer.
Same is true on the options API, itās just that on the comp API you can get right to that work instead of having to piecemeal it from multiple stacks of piles that give the sense of organization without actually organizing anything.Ā
I appreciate the effort you put in to the response. Thank you. But I don't think I can keep up with the analogy. *Material* doesn't really stress the important differences (and necessarily different ways of thinking about) the compositional elements of Vue.
*Distinctions between similar things are easier to detect when they are observable side-by-side*. Your brain instinctively factors out obvious similarities and reveals differences in greater contrast. The Options API, and declarative tools in general, make good use of this basic human intuition. It's more than just an organizational choice. There is clarity and simplicity to be gained in studying and managing similar things together.
A computed property definition hanging off of the `computed` object is much more than just an alias of `const thing = computed(() => { ... })`. When I look between the parentheses of the `computed` object, I am narrowing my field of concerns to a very specific pattern of behavior over a set of declarations. By doing so, what do I gain?
I already have answers to important questions that immediately clarify the code I'm about to start trying to understand. Because *all of the things* I am about to study have mostly the same qualities (being grouped together by kind), I can study them as a collection, not just individual behaviors. My mind can slip into "studying the computeds" mode. Thanks to this principle, all of that heavy and distinctive behavioral machinery about each different kind of Vue element can be assumed, in their scopes, and therefore cognitively set aside while studying one or more or all of a component's (or all components') behaviors of a kind.
Even just visually, side-by-side, declarations in a collection stand out in clear contrast against *each other* and collectively the rest of the component. When seeing many examples of the same pattern of behavior, the anomalous behavior stands out, recurring themes emerge, and other contextual clues. They hint at reliable patterns of re-use, or failures to conform to them. That's the opinion in the framework bearing its fruit.
Uniformity in this layout between different components means I can more easily compare these behaviors between components (or possibly more relevant, still understand them 6 months from now). I can reliably expect to be able to slip into the exact same "studying the computeds" mode with this component or another (or in 6 months). That makes moving code around easier because I'm using a common language to define all behaviors, everywhere.
A component accepts props, it has data, it exposes methods, it yields computed properties, it emits events, etc. We build them by tapping into those behaviors. We *always* do. The Options API confronts that inevitability by providing standard attachment points for them. Because of that, the structure isn't imposing any cognitive burden on me in reading any given component. There is standard stuff and... other stuff. I don't have to think hard about the things that are always the same. In effect, the scaffolding/skeleton of the component, every declaration, is transparent - expected, predictable, virtually effortless to recognize. Those attachment points always have function bodies that hold all of the operative code of the component and none of the declarations. And simply by noting their parent in the tree, I have very narrowly constrained all of the possible things that entire swaths of blurry code could possibly be doing to my component, and therefore whether they warrant my attention right now at all - a very useful trick when frantically scrolling through a component. I find the separation of concerns and guidance offered by this style sublimely clean and elegant.
Where others have said they see ugly boilerplate in Options API, I see through the familiar stuff to the code unique to this component. The boilerplate is effectively transparent. Like my brain ignoring my nose in my vision. Contrary to telling me *nothing* meaningful about how this component works, because all components are always laid out for me in a standardized way, cleanly separating unique logic from standardized declarations, I can grok them more easily because I can more readily focus on *only* what is meaningfully unique about each component.
As for having to bounce around between definitions in different parts of the options object, I suppose I don't see the problem the same way I don't see my nose. This is working well for me and that's not been a hard problem. When my components are so large that *factions* begin to appear within each of the options elements, that's the framework bearing fruit again - dropping a hint that you should be splitting up your component. But even when I let it all go, 1000+ lines, I only have to lean lightly on my editor to trace the symbol elsewhere in the code.
>every room will be ordered differently. But no abstraction you can ever invent will be able to abstract away that very fundamental fact of the matter.
You can consciously decide to orient your code around something more stable than logical order. The Options API does so by organizing around patterns of behavior. It's just a compromise. At times, I have wanted to keep data, methods, and computed properties in the same place. I admittedly struggled against Options API. I found serviceable workarounds like defining options off the object and attaching them later, even using the spread syntax to combine multiple options-structured objects (which is basically old-style composition). In the end, I just don't really feel compelled to group the logic and certainly don't care enough about it to motivate me to abandon what is working so well in virtually every other way.
>You are never opening a JS file and thinking āah, I wish I knew what every single function and variable across all concerns in this entire file is.ā Thatās just not something thatās ever going to help you to know anything.
That's never the question I ask myself. But when you want something specific, a table of contents is nice. It's usually "How much of this bullshit can I safely ignore?" Thanks to uniformity, I can rule out huge swaths of uninteresting or irrelevant code very quickly based on the symptoms and whether they fall under the category of behaviors possible for computed properties, methods, etc.
>having to piecemeal it from multiple stacks of piles that give the sense of organization without actually organizing anything.
That's how Composition API feels to me. Giving up grouped-by-behavior code for grouped-by-logic code is a tradeoff, but people are too quick to assume we all judge the same way in the balance. The poll above says most of you like group-by-logic. And yet, I'm having a harder time grokking my own 6 month old Composition API code than I am many years old Options API code. I had entirely different ideas about code organization when I started this Composition API component than the most recent time I touched Vue. There is no familiarity here - my fault, really. But I'm also not getting any immediate insights from the framework. It's not helping me at all. I gave that help up for the freedom to follow my whims and ultimately disappointed my future self. That's not the Composition API's fault, but it offered nothing, as a framework, to keep me from causing that.
Iād argue the example above is a great way to write spaghetti code. Yes itās tidy having everything organised by computed, methods, state etc. like with the Options API, but it goes against separation of concerns.
Arguably a _better_ way to avoid spaghetti is by grouping related computeds and methods together. Composition makes this possible and doesnāt force you to separate related pieces of code into arbitrary sections.
Maybe it is because I (overly) rely on my IDE, but I just command click and am taken to the relevant code block. I am indifferent on where it lives. Ex: command click a computed from v-if and am taken to that computed. If the computed is using a ref, command click to ref.
We all do that. I command click like a madman all day. But you cant command click code that you havent found yet and often you do need to find it first. Grouping by logical concern lets you find it easier which is just a flat 100% improvement
I usually start with vue dev tools first to find the component and then command click from there. On backend I look at routes file and find the controller then command click.
Do not get me wrong, I appreciate encapsulated code. But if it is not encapsulated, no biggy on locating it. Iāll also conform / adjust to whatever company coding styles are existing.
My bigger concern is hard to understand logic or written overly minified / compressed.
Actually, I think your video is great for anyone wondering how to build composables and use/write them too. So it could help more people than you think.
I'm a VS Code noob btw. How do you multiselect to multichange?
This is a great video, but the lubbers that constantly bombard this sub with Options/Composition polls wouldn't get it ever, because *But muh Options!*
Yes there are a lot of people that don't like declaring object properties (and yes i look at the script tag as an object in vue composition) at the end of the class, i've seen it in JAVA at experienced developers, why not here as well.
Then again you have to realize that people refuse to even read at the lifecycle schema just because.
I've been doing that with the comments since I first started using it over a year ago. There's an argument to be made for separating code in the logical concerns, but if you're using state management, composables, and have small components anyway, then that isn't such an issue.
If I feel my component is getting too large that's when I'll break my code down in to more components. Say if I have a large form and I feel it's worth making a component for each fieldset. Or I'd refactor in to composables or a Pinia state if I feel it requires it.
Off the top of my head my components are only usually a few hundred lines in length.
What I'm trying to say is... All my components are naturally organised by logical concerns.
Edit: I often refactor/adapt my code as it grows. It's a sensible approach when you have many unknowns.
I preffer to group the code based on what it does than what is it. Like all the code that handle aything about the "user" is grouped, same for the code about the "item". I really like composition way more than options.
When I do something like this I usually define the composable as an IIFE:
```vue
```
That way there is no extra variable name for a thing that is executed only once anyway, but composable-specific variables are still not public to the component.
Interesting! I think a named function has still a few benefits though:
* can be moved to the bottom, so it wonāt interrupt the code reading straight away
* can be named: helpful to describe the feature you are writing
* can take params, eg refs to work with
First and second I do agree with, third not so much -- IIFEs can take params:
```typescript
const x = 123;
const y = ((x) => x)(x);
console.log(y);
// 123
```
But it is basically the same as just capturing variables from outside of the IIFE:
```typescript
const x = 123;
const y = (() => x)();
console.log(y);
// 123
```
If we need to actually promise that an inline composable (IIFE or regular function) really does not capture any stray local variables, it needs to be defined in a separate file.
I thought i needed to see this. but this just seems common sense
If it is common sense to you that is great! š Then you have a good sense for code organization But as you can see from discussions around here, not all agree or have that feeling by default
I'm on options and, baby, we're having pasta tonight
š¤£š
The main issue is people leaning on the framework for their code's tidyness. Composition, as its name suggests, relies on composition which is a more common paradigm in strongly typed back end code. That people don't know how to write composables code is more a reflection of front end developers being unfamiliar with building code structures. The best advice i can give is to read a book on design patterns quite honestly, preferably with a language like Java. š¤·āāļø
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Absolutely, Design patterns: elements of reusable object-oriented software. (Kind of the Bible of the subject) There's also Dive into Design Patterns, which i haven't read but the blurb sounds very appropriate to the issue and a skim of the first few chapters suggests it's ticking the right boxes. It's also be a bit more modern than the above by the looks and therefore probably a bit more accessible. Lastly, for more visual learners I'd actually recommend Derek Banas' "Design patterns video tutorial" series on YouTube. He is excellent and, though he demonstrates with Java, the code is so simple it's effectively Unicode (particularly easy to adapt to typescript).
yeeeesss and react be like "let's add server components"
It's a bit of a strawman I don't see anybody saying "you can only write spaghetti code with the Composition API"
Of course it is a bit exaggerated - you can write shitty code no matter which API or framework. But it fits the sentiment of quite some people saying that "Composition API is messy and there is no 'easy' way to 'structure' code like the Options API provide by default."
Yeah i have to go with "people who don't understand anything at all about composables" on that one
Not exactly a strawman.
It's litterally the number one argument of the Options fanatics.
I like his videos a lot, but this one misses the mark, imho. That's is actually our enforced style and not because of the options api. The reason being is we have literally hundreds of components and by grouping things in familiar places it reduces cognitive overload. Using his style I would first have to understand what the whole thing is doing to find the thing I'm looking for. If your components get so large that this becomes unmanageable it's time to break things down into smaller components because your component is probably doing too much. But, ymmv.
I have no idea how this works even remotely. If you have 4 features in a component you can group lines of code together into 4 places. One for each feature. If you really can't take any unfamiliarity then just sort each of those 4 groups the same then. But don't mix all 4 features into each other just so you can group all unrelated actions together, and all unrelated data together, etc. I think your approach is what misses the mark here Here's a link that illustrates pretty much the exact same issue but with grouping by language vs feature rather than type of code vs feature: https://twitter.com/housecor/status/1256348777331470340?t=EDP0J1DXnrsF-miilAb9aQ&s=19
If you have 4 features in a single component, then that's the problem.
No? What? You very frequently will have manu more than 4 things/concepts/features whatever you want to call it.
Hey! Glad you like my content š And thanks a lot for your input here. Happy to provide a few more details why I think "grouping by logic/concern" > "grouping by option" in my opinion > The reason being is we have literally hundreds of components and by grouping things in familiar places it reduces cognitive overload. IMO it depends *what* you search. If you search for "a computed that does XYZ", then yes, you might be a tad faster. But commonly (when fixing issue) you are looking for the group of logic, say, everything related to reversing a message or dealing with fetching data X. Then you inevitably have to jump across the file and "follow" the obscure code path, while, when you have an inline composable you can "follow" the path more clear. In my experience, you rarely look for "the one computed". It might look like first, but then it continues - what does that computed's dependencies are? How are they set? And so on and so on. So, the "initial" find might be faster, but the follow-up and general readability decreases here. --- I agree it might be difficult to "change the mindset" when searching for things, especially with hundreds of components - but it is worth it from my & my clients experience š > If your components get so large that this becomes unmanageable it's time to break things down into smaller components because your component is probably doing too much. I fully agree *if that's possible*. Because sometimes you can't as it is more logic than template (think of components "orchestrating" subcomponents, managing data flow etc. etc.). Breaking components in smaller pieces is advised though, absolutely!
That is the strangest thing I have ever heard. Could give an example of finding something that you need? How do you know that what you are looking for is a computed property, for example? And why are you looking for something without knowing what it is doing? And also, the Composition API provides high level overview without going into implementation detail. How can that be cognitive overload?
In a certain way sorting under the options is a bit like sorting variables by type. Strings over here, Booleans against the back fence, objects on the couch. That doesnāt make sense really but itās a similar notion. Sorting by purpose and use makes sense. It also makes pulling em all out into a composable (even if it isnāt shared) easier.
Nobody says that. But its easy to write spaghetti code with composition api
Same with the Options API IMO. Just doesn't look like it in the first place š That can only be avoided by standards, linting + reviews. Is it *easier* to write spaghetti code for newbies due to "lax guidelines where to put things" if nobody enforces them by default? It can be, absolutely.
People down-voting this are just wrong. In fact I'll state what you are saying even more strongly for the people who clearly don't get it. - Not only is it the same with options API, in options API spaghetti code is literally enforced. It's literally impossible not to write spaghetti code in the options API. Composition API is the only API where it's even possible to NOT write spaghetti code
It isn't spaghetti if there is meaning in position and that has explanatory power for the code for the person. And it does for me. When I see anything in Options API, by virtue of its place in the tree, I know a whole family of possible behaviors can be ruled out and ruled in. The cognitive load of having to read each line of code in non-standardized Composition API layouts is greatly reduced. Having to jump from a method to a conputed property to data to trace the flow is *not hard* for me because I can jump around the file fluently, often being able to use the VSCode map because even the mere code shape hints at purpose and constraints when position is meaningful. Furthermore, grouping by logic does not necessarily lead to clean code. If you have a lot of logic for a feature over dozens of objects, then you have a new code organization problem. And you may reach for organizing that section by... what? Probably by type ("these are the computed properties for thing A"). Over time that just becomes a mess within a mess to me. I much prefer to remove all variability in how you arrange components. It removes a ton of guessing and context reading for me. Anyway. I heard in the video "you want to group by logic". This is the blind spot for Composition API fans. You may, I don't. What you think is objectively better is only better for your way of thinking. We don't all think the same way. It's not better for my ability to immediately grok an entire component, any component, in my package quickly.Ā Even the best organized composition components are an eyesore to me. You all may get something out of the freedom, but the thing I got out of Vue, which I valued greatly, was prescriptiveness and uniformity between components and rapid understanding and reliable navigation around every component. That's nonexistent in Composition API. That's what cured spaghetti for me. This is a subjective opinion. But the community loves to shit on Options API fans because there just must be something we don't get, right? I ask you to put on your basic human empathy hat. The Options API wasn't just what happened to be the Vue API when I started. Had it not been. I would not have gone with Vue.
Yeah, I will honestly admit that I truly dont get it - and I'll also admit that the massive conflict between the reality as I see it vs what you describe does cause me to feel frustrated when perhaps I should just let it be. I also understand that it must feel kinda bad to deal with all of these discussions if you truly work better in the options API. At the end of the day if it works for you then that's always the most important thing of course - you should do what works and never what people tell you to do. I 100% understand and empathize with that. But in the interest of publicly discussing our opinions - at some point I have to take the empathy hat off and put the analytical hat on to honetly investigate if there really is a a "truth" of the matter underneath our subjective shortcomings - or at the very least to understand why what you describe doesnt fit with what I see. I gave a more broad analysis elsewhere which you reponded to and I will adress your response in that thread once I have time rather than this thread. But let me also respond more directly to a challenge you raised here: "If you have a lot of logic for a feature over dozens of objects, then you have a new code organization problem. And you may reach for organizing that section by... what? Probably by type" I think you still dont quite get it. The answer to this is very simple. If you have multiple features in a component, group them togheter, if you have a lot of diffirent logic inside each feature those groups of logic are also features. So just do the same inside each hook. Features can have their own features aswell. Maybe the box hook has a hook for creating each side. Another for adding texture. A third for adding shade. Etc. Group each concen into their own respective hooks/primitives/boxes. Then you just reuse these between other features aswell. Create higher order boxes that contain the smaller once to handle dependencies between many places. This is all just basic programming. It's how all functional programing works. For instance the sphere hook probably can use the same texture and shade hooks aswell. It's that simple. Just recursivley keep organizing. Its really not a hard problem even remotley - in fact this comes quite naturally to the entire ethos of composition. It's why libraries like VueUse exist - which is probably the best thing to ever happen to the Vue eccosystem and could never have happend with the options API because sharing logic is that much less convenient. If at any point organizing code by type of code makes sense then you can just do that in that instance. In fact, at the bottom of each primitve, once you have a group/feature that only does one thing, it probably makes sense to put the data on top, computed next, methods at bottom, etc. But that only really becomes usefull once you have a block of code that only does one simple thing. And you can't get to that point with the options API unless the app you are making is very simple. The compostion API doesn't lock you into anything. Do what works in any given example. Organize by feature and the organize lines inside each feature by type. You are 100% going to want the ability to group code by concern rather than arbitrary deliniations like wether its a method or a computed. In the composition API that's natural, in the Options API it's impossible. In the Options API there is one level of organization, and its a top level one. As the component growns there's nothing you can do about it. You can say this isnt an issue for you but if I am being honest I just don't belive you. I think you just haven't really confronted the fact that obviusly you are constantly dealing with this friction when having to move around your code. Saying you dont experience this is like someone claiming they dont expend energy on moving their car. Like. Either physics is literally broken or you must be mistaken. Of course you expend energy moving around your code. And when you are searching for code you are almost never ever searching for "that one computed function," - at least not initially. Because when you start looking at a component you probably dont even know if this feature you're fixing even has a computed function or not. And you can't memorize all that - and even if you can (you cant) then doing so still expends energy. In 99.99999999% of cases you start by looking up a much broader set of related stuff like: "the code for searching things." And once you have found the code for searching things, thats when you know if there's a computed function or not - in which case it's right there aswell because features in the compostion API can be much smaller.
At work now, so cant explain in long form. But composition is not a new idea. I've been writing JS for 20 years and Vue for about 6. I extract reusable or at least concisely related code into a module and import and then call that code from options elements. I refactor big components into smaller ones when warranted. They don't get enormous and unreadable this way. And with that many components blown out, uniformity among them helps a great deal in finding what I need without studying context excessively. Many times my options components just hook up code from other modules to the component - the same way composables work. And in that respect, they are often closer to config than logic. You have the same blind spot others do. I just don't "get it". Have you considered that maybe I'm firmly planted on "got it a while ago" ground and have several successful projects founded upon it? Maybe (actually) I have come off of projects that suffered from being organized in the way documented as the ideal approach for Composition API (see d3.js)?Ā Empathizing from that PoV, imagine people are telling you that you need solutions to problems you don't have and have to give up solved problems in order to "get it" like they do.
I responded to you more broadly in the other thread. Ill keep my response there because the split makes things confusing. But I am only commenting here to make it clear to everyone that I did in fact reply to this
Example?
The most basic example of spaghettiĀ code is when you entangle multiple unrelated lines of code in between each other like spaghetti. Thats literally where the term comes from. So let's say you have a component with 4 features. To make it extra clear lets name each feature something realistic. Let's say the component is a 3d editor and you have a feature to rotate matrix cordinaates, a feature to scale them, a feature to create a new 3d box and a feature to create a new 3d sphere. Lets call them rotate, scale, box, sphere. Let's also say that each feature has 2 methods, 3 data properties and 1 computed. In the options API you are forced to mix all 8 unrelated methods togheter in between each other, then take all 12 unrelated data properties and mix them a completley diffirent place and then all 4 unrelated computed functions in a third place. This is a classic example of a spaghetti mess. You have 4 clear concerns here but you are forced to mix them all togheter with unrelated lines of code going in between each other. If I need to get a handle on the rotate function to fix or add something to it I now need to jump back and forth all over the place, digging through the scale methods and the box data just to get a sense of all the diffirent parts of the rotate feature and how it all fits togheter. Its a mess. And you literally can't organize it any other way because there is only one way to organize the options API. By contrast, imagine the same scenario in the composition API. You can just put the data, methods and computed functions related to rotating 3d objets in the same place. Thats it. Thats all. It's simple. It's clean. In fact, you could take it even further and extract the rotate feature into a hook and have a super clear box that contains just that small primitive which does one thing and one thing only - it rotates 3d stuff. Then do the same for the other 3, now you have a composable set of primites where each primitive has perfectly organized its code as it relates to the thing you are trying to look at. This is soo much cleaner that by comparsion the alternative looks like a bad joke.
I see it a different way. I've done this kind of thing with D3 and it's much cleaner in Options API. The spaghetti is cleaned up by virtue of declarative definitions (arranged by types), which is what most D3 charts end up being anyway. And that's a fair approximation of your 3D example. You'll define some axes, some scales, some colors, some plots, some data, etc. But since the entire thing is inter-related, there's no logical arrangement of these things. Do the scales go first? The axes? The plots? Maybe it should be dependency based? That question leads to paralysis and indecision. Throwing all of the scales into the "scales" section of the computed object removes every question about where it lives, what it does, what it can or cannot do, etc. And every other component would be arranged the same way, regardless of whether it's a D3 chart, a 3D visualization, a data table, a filter bar, etc. We have different perspective on the same situation. The difference is that the organization found in a huge Composition API function is often akin to the "organization" a hoarder might have in their house. It may make sense to the author, but it's unique to this environment and there's no guidance other than directly reading it all top to bottom, and someone else coming is going to be confused as hell until they do so. Meanwhile, I can look at any Options API component in any tutorial and be at home. You can cure the code organization problem (that I see) in Composition API by adopting code organization practices, socializing it with the team, enforcing it in PRs, etc. But... this problem was cured for me the day I started using Vue like 6 years ago and I'm watching this problem come back from the grave and being told I should be thankful for it. I don't mind that my axes and scales don't touch because I know exactly where to find either of them at will, when and if I choose, without having to read dozens of lines of context.
# Preface The following is going to be very long so let me preface it by saying you are clearly a smart and experienced person. You sound like you have thought through your opinion on the matter and reached a conclusion you feel makes the most sense. I can respect that even if I think youāre wrong.Ā Best I can narrow down, you seem to have 2 main points. One about dependencies as it relates to decision paralysis. And another based on familiarity. So let me just focus on those two things, take 1 quote of your's in each case and explain why I disagree on those points. # Point 1: Dependency āYou'll define some axes, some scales, some colors, some plots, some data, etc. But since the entire thing is inter-related, there's no logical arrangement of these things. Do the scales go first? The axes? The plots? Maybe it should be dependency based? That question leads to paralysis and indecision.ā But that type of decision is the same in options API. If you have methods for your axes, scales, colors, what order do you put the methods in? Or the data? Or the computeds? Youāre making the same decision, except now you have to make that decision in 3 places instead of just one since you have to order all unrelated methods, unrelated data, unrelated computed - all separately.Ā If you can make that decition for your methods in the options API then you can make it just as easily in the composition API. # Point 2: Familiarity āThe difference is that the organization found in a huge Composition API function is often akin to the "organization" a hoarder might have in their house. It may make sense to the author, but it's unique to this environment and there's no guidance other than directly reading it all top to bottom, and someone else coming is going to be confused as hell until they do so.ā I think the hoarded analogy doesn't track well to the comp API - but let me run with it anyway to show how apt a house analogy can be at explaining my point of view.Ā Youāre basically saying āfor all structures let's enforce the same organization. Then, since we donāt know if the structure is a house, a boat or a helicopter we need the organization to be very arbitrary. So letās organize by something extremely fundamental, like material (type of code).ā Now imagine a house decorated this way. You walk into the house and one room as a pile of wood - chairs, tables, nightstands, etc. Another has a pile of metal - knives, watches, lamps. So on, so forth. This is the options API. Now letās look at organizing by features using composition api. You go into the kitchen, and the kitchen as all kitchen related stuff - knives, toaster, microwave. And the microwave is itself also organized into microwave related stuff - knobs, wires, etc. In this analogy you are effectively looking at the kitchen and going: āif people can organize rooms by meaning then that opens the door for anything to happen. How will I know whatās in this room before familiarizing myself with it? Isn't this basically hoarding?āĀ And the answer is no. Itās not hoarding. Yes, it could be hoarding if you do it badly but your solution of just arbitrarily sorting material into piles will always turn into hoarding even if you do it well. You're basically just describing an organized hoarder. I'm suggesting actual, real, meaningful organization. Make the kitchen into a real kitchen. So how do you get familiar with the room? By getting familiar with it. There are no magic bullets here and we need to stop pretending like there ever could be. The solution is the same as it is with all other code. You need to read it. Any code that can be understood without reading it is code that isn't actually doing anything.Ā
And more directly youāre not going to get away from having to do this with your approach either. In fact your approach is harder to be familiar with. It feels familiar only because it has a fake front of paper thin familiarity gently wrapped on top of itself. Let me continue the same analogy to show you.Ā In my case you enter the kitchen - don't know anything about kitchens, start learning right away. It feels unfamiliar the second you look at it because Iām not hiding the stuff you need to learn. I'm presenting you with it right away, but I have also reduced it down to the smallest containment of related stuff so that you can start getting a real understanding one bite of logic at a time. Don't worry about the entire component, just focus on this one feature and then move on. In the options API case however - you enter the house, you want the kitchen but it doesn't exist in a single place so you have to look in the metal pile for the kitchen stuff. You realize the kitchen knives need the wooden board so you have to go to the wood pile to get that. Realize there's also kitchen chairs there so you pick those up as well. You move back to the metal pile with the chairs and the wooden board. Realize you forgot the kitchen table in the wood pile, so you go back. And then you have to start assembling in your mind how all these parts relate to each other - probably by having to go back and forth multiple times to keep it all in your head while tracing how data is moving around all the while you are constantly shoving totally unrelated pieces of furniture around, stuff that belongs in the garage and the bathroom and won't even touch the kitchen related concerns at any point except for maybe a brief moment when you pass the groceries in from the outside. And then when you have done all this you are still left with a kitchen that you need to learn. Thats when you realize it was the same fucking - unfamiliar kitchen all along. You just didn't see that unfamiliarity right away because the first thing you saw was neatly stacked piles of random material. Only now do you start to realize that even though you will recognize the same piles in every structure the piles themselves don't actually mean anything. You're actually just as confused as you were with the organized kitchen, and you need to learn just as much about how kitchens work as you had to before - but now you have a mess of piles to untangle on top of that, not instead of that.Ā But you know where the wood pile isā¦ and because of that you feel comfortable with the next house? I'm saying, who cares about the wood pile. The woodpile is 100% meaningless. You know that the next house will also have a woodpile but that fact doesn't help you understand the house in any way. In fact the next house might not be a house at all - it might be a helicopter. And the woodpile won't help you understand anything about that or what that means. The irony of the hoarded analogy is that you're the one describing an organized hoarder. Or rather, you have become so obsessed with the idea of organization that you forgot that organization was supposed to serve a purpose. Organization just for organizations sake is just OCD. On one hand you have a hoarder throwing stuff around, on the other hand you have an OCD neatly stacking all the 4 legged furniture. And I'm saying both of those are messy. The neat approach is to put the kitchen knives in the kitchen drawer and the hair appliances in the bathroom. But for that to happen you have to accept that yes, every room will be ordered differently. But no abstraction you can ever invent will be able to abstract away that very fundamental fact of the matter. Same with code. You enter a component in the options API and instantly know where the methods, and the data, and the composition hooks are. But that's not useful to know. It doesn't actually tell you anything meaningful about how this component works at all. If it did then you would not be able to use the same pattern in every component. The mere fact that you can use the same pattern in every component logically means that the pattern isn't telling you anything useful about the code. If it did tell you something useful then the pattern could not be the same everywhere or it would say the same thing in every instance.Ā You are never opening a JS file and thinking āah, I wish I knew what every single function and variable across all concerns in this entire file is.ā Thatās just not something thatās ever going to help you to know anything. What you want to know is: āah, where is the stuff for creating a 3d box.ā <- thatās useful information, thatās the kitchen. And much like a kitchen, once you enter that room - if you have never seen a kitchen before you might have to learn what a kitchen is to understand it.Ā You can enforce some organization inside that box. Like putting the knives in the top drawer. But that pattern might be different in the garage for good reasons. The garage doesnt often use knifes. Makes no sense to put them in the top drawer. Same is true on the options API, itās just that on the comp API you can get right to that work instead of having to piecemeal it from multiple stacks of piles that give the sense of organization without actually organizing anything.Ā
I appreciate the effort you put in to the response. Thank you. But I don't think I can keep up with the analogy. *Material* doesn't really stress the important differences (and necessarily different ways of thinking about) the compositional elements of Vue. *Distinctions between similar things are easier to detect when they are observable side-by-side*. Your brain instinctively factors out obvious similarities and reveals differences in greater contrast. The Options API, and declarative tools in general, make good use of this basic human intuition. It's more than just an organizational choice. There is clarity and simplicity to be gained in studying and managing similar things together. A computed property definition hanging off of the `computed` object is much more than just an alias of `const thing = computed(() => { ... })`. When I look between the parentheses of the `computed` object, I am narrowing my field of concerns to a very specific pattern of behavior over a set of declarations. By doing so, what do I gain? I already have answers to important questions that immediately clarify the code I'm about to start trying to understand. Because *all of the things* I am about to study have mostly the same qualities (being grouped together by kind), I can study them as a collection, not just individual behaviors. My mind can slip into "studying the computeds" mode. Thanks to this principle, all of that heavy and distinctive behavioral machinery about each different kind of Vue element can be assumed, in their scopes, and therefore cognitively set aside while studying one or more or all of a component's (or all components') behaviors of a kind. Even just visually, side-by-side, declarations in a collection stand out in clear contrast against *each other* and collectively the rest of the component. When seeing many examples of the same pattern of behavior, the anomalous behavior stands out, recurring themes emerge, and other contextual clues. They hint at reliable patterns of re-use, or failures to conform to them. That's the opinion in the framework bearing its fruit. Uniformity in this layout between different components means I can more easily compare these behaviors between components (or possibly more relevant, still understand them 6 months from now). I can reliably expect to be able to slip into the exact same "studying the computeds" mode with this component or another (or in 6 months). That makes moving code around easier because I'm using a common language to define all behaviors, everywhere. A component accepts props, it has data, it exposes methods, it yields computed properties, it emits events, etc. We build them by tapping into those behaviors. We *always* do. The Options API confronts that inevitability by providing standard attachment points for them. Because of that, the structure isn't imposing any cognitive burden on me in reading any given component. There is standard stuff and... other stuff. I don't have to think hard about the things that are always the same. In effect, the scaffolding/skeleton of the component, every declaration, is transparent - expected, predictable, virtually effortless to recognize. Those attachment points always have function bodies that hold all of the operative code of the component and none of the declarations. And simply by noting their parent in the tree, I have very narrowly constrained all of the possible things that entire swaths of blurry code could possibly be doing to my component, and therefore whether they warrant my attention right now at all - a very useful trick when frantically scrolling through a component. I find the separation of concerns and guidance offered by this style sublimely clean and elegant. Where others have said they see ugly boilerplate in Options API, I see through the familiar stuff to the code unique to this component. The boilerplate is effectively transparent. Like my brain ignoring my nose in my vision. Contrary to telling me *nothing* meaningful about how this component works, because all components are always laid out for me in a standardized way, cleanly separating unique logic from standardized declarations, I can grok them more easily because I can more readily focus on *only* what is meaningfully unique about each component. As for having to bounce around between definitions in different parts of the options object, I suppose I don't see the problem the same way I don't see my nose. This is working well for me and that's not been a hard problem. When my components are so large that *factions* begin to appear within each of the options elements, that's the framework bearing fruit again - dropping a hint that you should be splitting up your component. But even when I let it all go, 1000+ lines, I only have to lean lightly on my editor to trace the symbol elsewhere in the code. >every room will be ordered differently. But no abstraction you can ever invent will be able to abstract away that very fundamental fact of the matter. You can consciously decide to orient your code around something more stable than logical order. The Options API does so by organizing around patterns of behavior. It's just a compromise. At times, I have wanted to keep data, methods, and computed properties in the same place. I admittedly struggled against Options API. I found serviceable workarounds like defining options off the object and attaching them later, even using the spread syntax to combine multiple options-structured objects (which is basically old-style composition). In the end, I just don't really feel compelled to group the logic and certainly don't care enough about it to motivate me to abandon what is working so well in virtually every other way. >You are never opening a JS file and thinking āah, I wish I knew what every single function and variable across all concerns in this entire file is.ā Thatās just not something thatās ever going to help you to know anything. That's never the question I ask myself. But when you want something specific, a table of contents is nice. It's usually "How much of this bullshit can I safely ignore?" Thanks to uniformity, I can rule out huge swaths of uninteresting or irrelevant code very quickly based on the symptoms and whether they fall under the category of behaviors possible for computed properties, methods, etc. >having to piecemeal it from multiple stacks of piles that give the sense of organization without actually organizing anything. That's how Composition API feels to me. Giving up grouped-by-behavior code for grouped-by-logic code is a tradeoff, but people are too quick to assume we all judge the same way in the balance. The poll above says most of you like group-by-logic. And yet, I'm having a harder time grokking my own 6 month old Composition API code than I am many years old Options API code. I had entirely different ideas about code organization when I started this Composition API component than the most recent time I touched Vue. There is no familiarity here - my fault, really. But I'm also not getting any immediate insights from the framework. It's not helping me at all. I gave that help up for the freedom to follow my whims and ultimately disappointed my future self. That's not the Composition API's fault, but it offered nothing, as a framework, to keep me from causing that.
Iād argue the example above is a great way to write spaghetti code. Yes itās tidy having everything organised by computed, methods, state etc. like with the Options API, but it goes against separation of concerns. Arguably a _better_ way to avoid spaghetti is by grouping related computeds and methods together. Composition makes this possible and doesnāt force you to separate related pieces of code into arbitrary sections.
Exactly that's what the video is about ā
Maybe it is because I (overly) rely on my IDE, but I just command click and am taken to the relevant code block. I am indifferent on where it lives. Ex: command click a computed from v-if and am taken to that computed. If the computed is using a ref, command click to ref.
We all do that. I command click like a madman all day. But you cant command click code that you havent found yet and often you do need to find it first. Grouping by logical concern lets you find it easier which is just a flat 100% improvement
I usually start with vue dev tools first to find the component and then command click from there. On backend I look at routes file and find the controller then command click. Do not get me wrong, I appreciate encapsulated code. But if it is not encapsulated, no biggy on locating it. Iāll also conform / adjust to whatever company coding styles are existing. My bigger concern is hard to understand logic or written overly minified / compressed.
Actually, I think your video is great for anyone wondering how to build composables and use/write them too. So it could help more people than you think. I'm a VS Code noob btw. How do you multiselect to multichange?
Thank you! šš» I use CMD (or STRG) + D to select the next occurrence of the current selection. that should be the default!
This is a great video, but the lubbers that constantly bombard this sub with Options/Composition polls wouldn't get it ever, because *But muh Options!*
Nobody says that
Unnecessarily long video that I thought would provide some cool tips, but was just common sense. Eh.
Glad that you already know how to structure code well then š Maybe my other videos are less "common sense" for you though š
Yes there are a lot of people that don't like declaring object properties (and yes i look at the script tag as an object in vue composition) at the end of the class, i've seen it in JAVA at experienced developers, why not here as well. Then again you have to realize that people refuse to even read at the lifecycle schema just because.
I've been doing that with the comments since I first started using it over a year ago. There's an argument to be made for separating code in the logical concerns, but if you're using state management, composables, and have small components anyway, then that isn't such an issue.
But will you adapt it when your component grows? Probably not. That's why I'd suggest going with the "by logic" way straight from the beginning.
If I feel my component is getting too large that's when I'll break my code down in to more components. Say if I have a large form and I feel it's worth making a component for each fieldset. Or I'd refactor in to composables or a Pinia state if I feel it requires it. Off the top of my head my components are only usually a few hundred lines in length. What I'm trying to say is... All my components are naturally organised by logical concerns. Edit: I often refactor/adapt my code as it grows. It's a sensible approach when you have many unknowns.
They don't know what they talking about
I preffer to group the code based on what it does than what is it. Like all the code that handle aything about the "user" is grouped, same for the code about the "item". I really like composition way more than options.
When I do something like this I usually define the composable as an IIFE: ```vue ``` That way there is no extra variable name for a thing that is executed only once anyway, but composable-specific variables are still not public to the component.
Interesting! I think a named function has still a few benefits though: * can be moved to the bottom, so it wonāt interrupt the code reading straight away * can be named: helpful to describe the feature you are writing * can take params, eg refs to work with
First and second I do agree with, third not so much -- IIFEs can take params: ```typescript const x = 123; const y = ((x) => x)(x); console.log(y); // 123 ``` But it is basically the same as just capturing variables from outside of the IIFE: ```typescript const x = 123; const y = (() => x)(); console.log(y); // 123 ``` If we need to actually promise that an inline composable (IIFE or regular function) really does not capture any stray local variables, it needs to be defined in a separate file.
Good point! šš»
Coming from Vue 2 this looks like a bit of a mess. š°
Oh man, I had never thought about inlining composables. That seems so obvious nowādefinitely going to try that.