Actually, I work in web app with vuejs as frontend framework.
in a particular situation, I want to communicate two separate components.
I know there are many ways to do that, especially with vuex that can help us to create a maintainable application.
in my case, i found we can manipulate data between components by bus events and with mixins (by $emit and $on event) also.
for that, i want to know :
how bus events and mixin work exactly ?
what is the difference between them ?
A mixin is a partial component spec. You include mixins in a component to compose functionality.
An event bus is a communication channel on which events can be emitted and listened for. Every Vue instance is an event bus.
Related
In Angular, there's a specific "service" layer intended to hold mockup services returning dummy data initially, which are replaced with real calls to the backing RESTful services as development on a project proceeds.
In Vue, is there a recommended location or layer in which to put such remote calls using axios? I can see them being placed inside the methods of a Vuex singleton or scattered through the script portions of single-file components... I imagine also that there might be some way to provide them to components via dependency injection.
What is the best practice?
Ty in advance.
Yes, if you're using Vuex, you can place Service components that wrap your Axios calls, which are then called from the vuex store.
So the hierarchy goes Component -> Store -> Service Component -> Axios
In my app I got service classes like SpeechRecognizer, VoiceRecorder ...
I wonder should I put them into the state of application, my personal opinion that they don't form the state, so then where to put them.
Also to notice, SpeechRecognizer is initialized with callbacks that are called when certain event occurs, so who shall subscribe to them and how to implement that subscription ?
I want to create a VueJS mixin that adds a couple of methods to the parent. In order to do this I need to store some data too.
Is it possible to store data in a mixin that can be accessed by a component that uses the mixin?
You should use some centralised state mechanism or more popular option vuex to store the data and manipulate it from the methods of mixin.
Here's what I'm trying to do---add a listener to a fluxible event to do an ajax call. In Redux, this is called a side effect and there are several ways of doing this (ex: create "side effects" using redux-saga, which are just listeners that do stuff). In Flux, one approach is to do side effects in the Store.
What about fluxible?
From what I can tell, the way to do this is in the Store. But I don't see a way to get the context. So perhaps there's another way to do this?
You should do ajax call in action. Action receives context, where you could provide plugin to do http call. Stores should contain only application state and have only synchronous code.
In structuremap you can control the lifeCycle of an object you register, normally some interface to a concrete type as follows:
x.For<IMyInterface>().Transient().Use<MyObject>();
So I can control the life cycle. However when resolving objects (Concrete) types that are not registered the life cycle defaults to what seems to be Transient().
This is obviously a convenient feature of structuremap as I surely dont want to register each concrete type.
However is there a way to override this life cycle without registration?
Furthermore it would be great if you can specify the life cycle of an object as an override much like:
ObjectFactory.With<SomeUnregisteredConcreteObject>().LifeCycleIs(...)
In such a case the life cycle would be modified for the next resolution to GetInstance
Any idea how any of this can be done?
You could create a child container & register the component:
var child = ObjectFactory.Container.CreateChildContainer();
child.Configure(config => config.For<SomeUnregisteredConcreteType>().Singleton());
var #object = child.GetInstance<...>();
I assume that the reason why you didn't want to register was because you didn't want the registration to hang around. I think this solves that problem.
I also don't know of built-in a way to specify a default lifecycle. However, I think it's probably possible using the IAutoMocker interface. You could probably browse through the code in that whole folder to figure out how to do it. The AutoMocking hooks into the container so that a component is requested that isn't registered, it calls into the IAutoMocker and gives it a chance to register a component. I imagine that you could use IAutoMocker to register components with a different default lifecycle.
If you succeed in this, I hope you send a pull request or write a blog post to share with the rest of us.