Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 months ago.
Improve this question
I wonder if mixin function is used in vue3.
Mixin allows script logic to be imported from other files.
Can composition api use the same function as above?
mixins are no longer called mixins in Composition API 1.
But it's only the name that has been dropped. Their functionality is, in fact, the bread and butter of this API.
First of all, Composition API allows you to move the entire logic of a component inside its setup() function. That's, mostly, what it is all about.
Might not seem that big of a deal at first but, when you think about it, it actually is, as it allows grouping code based on whatever criteria you want, not necessarily by the the type of component member - e.g: (reactive) data, computed, methods, watchers, etc...
Secondly, once a grouping criteria has been defined, the code can be taken out of the component, exported from its own file, and imported into any number of components, using a useStuff() function.
These are the new mixins: Composables. Quite similar to React hooks.
In fairness, I find Composition API a better name than Mixins API.
1 - technically, that's not true. They still exist for backwards compatibility, but they're no longer recommended. Composables are the path forward.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
This post was edited and submitted for review 7 months ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
I am a Vue.js developer who is coming up to speed with the the new features added to Vue 3, from Vue 2, namely the Composition API (added in Vue 3).
For State Management, it appears that along with the release of Vue 3, the community is shifting from using Vuex to Pinia.
What is the difference between Pinia vs Vuex? Conceptually, what has changed from Vue 2 to Vue 3, that makes Pinia a better fit for Vue 3?
Thank you.
In short, Pinia's API is much simpler and intuitive. It makes using stores a breeze, even for junior devs.
It brings the benefits of Composition API, but has a structure which greatly resembles the Options API, which you're probably familiar with:
has a reactive state, equivalent of data function in Options API
has getters, equivalent of computed in Options API
has actions, equivalent of methods in Options API
does not have mutations, as any change to state now registers an implicit mutation, regardless of where it's performed
Additionally, in Pinia:
actions are no longer necessarily async, they can be either
actions don't need (and don't have) the first param (action context) as you no longer need commit, dispatch, rootGetters, rootState
other stores can now be invoked directly in any actions/getters, even allowing cyclic dependencies; this reduces the need to nest stores, although still possible
all stores are now dynamically registered at runtime (when they are invoked for the first time; the store starts empty)
inside actions and getters functions, this is the current store and provides direct access to all state props, actions and getters
you also have typed direct access to all actions, getters and state props on the object returned by the function (e.g: useSomeStore) returned by defineStore(); it's all TypeScript friendly, no workarounds or type casting required.
More in-depth explanations and reasoning on the dedicated page to differences between the two plugins.
According to declarations by plugin authors, Vuex 5 will have a similar API to Pinia's and they are likely to merge at some point.
As outlined in comments by Tony, Pinia is now the officially recommended state management solution by Vue team.
Vuex is now in maintenance mode. It still works, but will no longer receive new features. It is recommended to use Pinia for new applications. -- [added by Evan You in dec 2021].
Ref:
"what has changed from Vue 2 to Vue 3, that makes Pinia a better fit for Vue 3?"
Pinia was designed for usage in setup(). So much so, that it has a dedicated page on how to use it outside of setup().
More importantly, you are implying Vuex is a better fit for Vue2 projects.
Technically, that is false.
Both plugins offer the same functionality but Vuex has more boilerplate and, overall, a less intuitive syntax. Therefore it requires better trained engineers, for longer periods of time.
If you choose Vuex, your project costs will grow proportionally with your project's complexity, without any benefits.
I want to take a moment to answer my own question, after doing some research and giving a talk on this at the Vuejs LA Meetup (Los Angeles). Thanks also to the others who already answered to help with this response.
TLDR: In Vue 2 you -could not- easily control the shared Global State using "just Vue," so you needed Vuex to manage Global State shared throughout your app. (You can manage a component's local state, but not "Global State" that is the shared state across your app, without using something like Vuex.) In Vue 3, using the Composition API, you -can- create a place to manage Global State, so you can very easily just "roll your own" State Management system. So now, in Vue 3, yes, you basically can do this on your own, but you might as well use a standard one everyone is using, Pinia.
Full Explanation: For those who are coming up to speed with Vue 3, the big addition is the Composition API. For Vue 3, Vue 2 basically got re-branded the "Options API" and now there is an additional "Composition API." Please don't confuse "new" with "better." The Composition API is not better. It's just different. The Options API (aka, the Vue2 way of doing things is still fantastic -- and you should continue to use it).
The main difference between with Options API and the Composition API is organizational. The Options API (again, aka The Vue 2 Way) helps you organize your code a certain standard way -- basically one of the best features of Vue is the clean organization of each component. Those 3 <template>/<script>/<styles> blocks in each .vue component make it a pleasure to use Vue.
The Composition API was basically created for the occasion that you need to break out of that paradigm. Imagine you need to have the same logic, like Search, in the <script> section of your code. But you need the Search ability in 3 places. Instead of having the same redundant code three times, you can now extract that Search code to a new file, call it something like my-search.js, and access that search code from one place by importing its functionality into each of your components, staying DRY. Moreso, using the Composition API you can do this while maintaining reactivity (in Vue 2, you could have an external file, but you were basically "leaving Vue" and that was a problem). Now, using the Composition API in Vue 3, you can create a separate area to focus on shared logic, like my-search.js, and Vue continues to be aware of it, so you don't break reactivity.
In Vue 2, the community solved this Global State Management issue by creating Vuex. It was a plugin that allowed you to control state outside of the components, i.e., control Global State while remaining reactive (i.e., it did not break state).
Let's apply this new ability given to us by the Composition API to Managing Global State. If you can create a new external.js file that remains functional within your Vue app, that retains state, you can easily write your own Global State Manager (replicating what Vuex does). Imagine creating a file called global-state.js and making all of your Global State updates there. The Composition API makes this super easy to do.
So now, because of the Composition API in Vue 3, we basically do not need any external state management tool. That is why, when Vue 3 launched, every forum post was asking questions like, "Why do we even need Vuex anymore?" In Vue 3, we don't need Vuex anymore because we can Manage Global State on our own using the Composition API.
So last, why Pinia? Well, basically, standards. We could all roll our own, but we might as well use a light-weight plugin that is standardized (I would bet that Pinia is written using the Composition API — please correct me if I'm wrong here). Moreso, because it's a standardized process, and the new community-backed way of handling Global State Management, it comes with the bonus of integrating well into the rest of the Vue ecosystem of tools, like Vue DevTools, and has its own plugin system.
Hope that helps answer the original questions I was asking, focused on the concept: "Conceptually, what has changed from Vue 2 to Vue 3, that makes Pinia a better fit for Vue 3."
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Lately I've been hearing everyone talking about mobx, I've used (am using) Redux in a production React Native application.
I'm just looking to see if anyone has experience with both and can advise where each one holds advantages over the other.
I'll paste a summary of their approaches I wrote in a Reddit comment:
Redux is heavily influenced by Functional Programming principles:
It encourages use of "pure" functions, wants you to handle your data "immutably" (ie, make copies and modify the copies, don't directly update the original values), and focuses on explicit definitions of data flow and update logic.
It gives you features like the ability to do "time-travel debugging" (stepping back and forth between individual updates to your state, or loading in a copy of the app state from a customer crash report to see what was going on).
Idiomatic Redux code "normalizes" nested or relational objects, like a database. Each item is defined in one place, and other parts of your data would refer to that item by ID only, leaving lookups for later
The usual complaint is that there's too much boilerplate code, and that typical Redux usages involves things like string constants and switch statements.
Use it when you want to explicitly track the flow of data through your application, or want to see exactly why your application wound up in a certain state.
MobX is influenced by Object-Oriented Programming and Reactive Programming principles:
It lets you define specific pieces of data as being "observable", then wraps those up and tracks any changes made to that data and automatically updates any other piece of code that is observing the data.
It encourages use of standard mutating code, like someObject.someField = someValue, and someArray.push(someValue), with the real update logic being hidden internal to MobX.
Idiomatic MobX code keeps your data in nested form and maintain direct references from one object to another
One possible complaint would be that you don't see as much of when and how your data is being updated, and it may be harder to track through the application
Use it when you prefer an OOP style over Functional, prefer your data to be represented and manipulated by classes instead of plain functions, or want to write less explicit update logic and let the library do the work of managing things.
For more in-depth comparisons, I can highly recommend Preethi Kasireddy's talk MobX vs Redux: Comparing the Opposing Paradigms from ReactConf 2017, and Robin Wieruch's article Redux or MobX: An attempt to dissolve the confusion . I also have a number of other comparisons collected in my React/Redux links list.
MobX and Redux try to solve the similar problems using different approaches. The main objective being; state management in javascript applications.
The core problem here is effective and optimal synchronization of information between your primary data source and the user interface, through whatever layers and transport mechanisms you have in between.
#saiki link has already written a great comparative analysis rich with examples, which helps you understand what code would look like when written using MobX vs Redux.
MobX embraces an approach often called Declarative MVVM:
Redux embraces functional programming and referential transparency:
State is a plain javascript object. You never mutate it directly, but instead, derive a new updated state when something happens in the application (which result in action dispatch) through pure functions.
for more details you can go through this example byExample
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions must demonstrate a minimal understanding of the problem being solved. Tell us what you've tried to do, why it didn't work, and how it should work. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
How to serialize the ViewModel ($scope) in AngularJS? I'm planning to store the serialized value to a ASP.NET server-side div to persists across postbacks.
$scope is an object created by AngularJS to interact with the markup. It can contain methods that can be referenced from html. You can create a simple JavaScript object for storing and transferring data and keep it in your scope.
$scope.model = { name : 'my model' };
Not sure if you should serialize the whole $scope (actually, you shouldn't - it's a complex object. You should only care about persisting your own data).
Use:
angular.toJson($scope.YourData);
obviously, there's a method-companion fromJson: http://docs-angularjs-org-dev.appspot.com/api/angular.fromJson
I am not sure about how your ASP.Net application is structured, but here are some of my inputs.
If you plan to do postbacks with ASP.Net I would suggest you to rethink you client side framework. AngularJS and many such similar frameworks are not meant for working with postback model. Typically what happens when you use frameworks like AngularJS
The server based on the request, sends HTML content (initial view) to client browser
The browser renders the view.
The client side Javascript frameworks kick in provide the necessary functionality
From this point onwards there is no post back, most of the functionality is achieved using AJAX requests, which does not cause a browser refresh.
If a navigate is performed from one page to another the process described above is repeated again.
As you can see postbacks are not natural to this setup, and any effort to bolt these two model together would produce less than optimum results.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
One question that I have long asked myself is in object oriented programming,how should data such as settings and properties be passed around in an object oriented manner?
For example, most programs have options, say you have an option to set the undo level. This must be obtained and then set to a new value. If these settings are saved in an xml file, that section of the application (the option dialog) still needs some kind of xml parser to load the data. In another scenario where you would instead have an object that represents getting and setting settings, each area that needs this would have global access to all settings and a pointer to it would need to be passed around.
In a scenario like Maya or 3DS Max where these use huge gui systems to set object properties, how is this done in a clean and OO manner? The widget, needs to be given the data from the 3D object, and needs to send information to this object. Should a dialog know anything about 3D objects? Probably not. So how is this usually done?
In another scenario, I might need to update a status bar when my frame gets a mousemove. Does that mean my frame should have a pointer to my status bar?
Any abstract examples or readings about this would be appreciated.
Thanks
In a previous job, we had several XML files for our various apps, and much of the configuration was similar, but varied depending on the environment and execution context. Much of this configuration was usernames and password for third party services. When a password would change, we'd have to scour through dozens of XML files and make the changes, then, re-deploy dozens of apps.
I migrated all of the XML configurations to objects using interfaces and a type hierarchy. The interfaces allowed me to code against a common configuration structure, and get compile time support as well as use dependency injection to resolve the run-time instances. The type hierarchy allowed me to define the non-changing configurations once, in a base class, and only override the actual values that differed.
This would be overkill, I think, for a small app, but was imperative in our case.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am using PHPDoc and JSDoc for my source code. I know that there are tools to build an API out of those docs. However, what I am wondering is that how is one supposed to explain complex code? Do I just use multiline comments inside functions rather than explaining in the PHPDoc/JSDoc?
For example, consider this code:
/**
* Lorem ipsum dolor sit amet.
* #param {Integer} width
* #return {Boolean}
*/
function setWidth(width) {
// Very complex code goes here...
}
In the above case, how should I go for commenting the complex code? I do not think I can do that in the JSDoc since it is used for building an API (which is about "how to use" rather than "how things work"), right?
Are my assumptions correct:
JSDoc/PHPDoc is solely written for those who are going to use the function/method.
Comments within the function are written for anyone who needs to understand the logic behind the function/method.
Documentation is separate from API and source code comments, the documentation (that every software should provide) is written for those who want to use the software.
But what I do not understand is that what explains the software in an architectural level -- should there be a developer documentation, too?
What are your strategies to perfect documentation?
You document Public Interfaces with those tools, you don't want consumers of the API to know or care about the implementation details, you put those comments in the code itself. Also "perfect" documentation is not really a good goal. The BEST documentation is working example code that uses the Interfaces in a obvious manner. Unit tests fit this requirement nicely in most cases.
If you really feel the need to document something about the inner workings of a function, that mainly only the developers of the code need to know, phpDocumentor does have the #internal tag.
When you use the --parseprivate runtime option, non-public code elements (like private variables, protected methods, etc) become visible in your generated documenation. Text that you include via the #internal tag also becomes visible.
It sounds to me like the descriptions that you want to write regarding the internal method code would be good candidates for such #internal usage.