The Vue class component library uses the #Component decorator, and must thus be transpiled to work. Is there a way to use Vue class components without this decorator? Like, either a work-around or another similar library?
Use-case: Lower commitment for a legacy project, but still possible to analyze with tsc.
Transpiled environment is the expected scenario of use for Vue. It relies on custom .vue format and may lack some features without it, as well as the support of some third-party libraries because they rely on it.
The use of classes never was a good idea in Vue because it doesn't follow OOP paradigm. A class isn't instantiated directly but used as syntactic structure that is translated to Vue.component definition. Vue class components have inherent problems, one of which is poor support for TypeScript types. If Vue classes aren't already used in the project, there are reasons for them to not be the first choice.
In case there's a necessity to use Vue class components, this can be done in vanilla ES6 because decorators proposal is syntactic sugar, decorators are functions with specific signatures that are applied to classes and members and decorate them.
#foo
#bar()
class Baz {}
is the same as
let Baz = foo(bar()(class Baz {}))
Different decorator types are applied in different ways, also there are some differences between TypeScript and Babel legacy decorators.
#Component
class Foo extends Vue {
#Provide('bar') baz = 'bar'
}
is translated to
let Foo = class Foo extends Vue {
constructor() {
this.baz = 'bar'
}
}
Provide('bar')(Foo.prototype, 'baz')
Foo = Component(Foo);
With Vue 3 typescript is well supported, you could create your component as follows :
import { defineComponent } from 'vue'
export default defineComponent({
//the component options like data,props,computed...
})
For more details check the official docs
A running example to get started
Related
After reading the plan for Vue 3, I noticed that the statement mixins will still be supported. However, Should I convert all of mixins components to class-based-components in case that Vue stops supporting mixins in the future?
mixins:
export default class MyComponent extends mixins(A, B, C) {
}
The class API that was originally planned for Vue 3 has been dropped and replaced with the composition API. While mixins will still be supported, composition functions have a number of advantages, such as avoiding namespace clashing, making it clearer where properties come from, and playing friendlier with Typescript.
Once Vue 3 is released I would recommend not writing more mixins but using Composition Functions. It'll be up to you to consider whether you rewrite old mixins - it will depend on whether you think the benefits of composition functions outweigh the initial cost of rewriting old mixins.
I have code in behaviors and in mixins. If I use both the mixin and the behavior in an element, the behavior can use functionality from the mixin and vice versa.
It seems a bit weird to write code that way though as you aren't making sure that the mixin is there from the behaviors' perspective, you are assuming the element includes both.
Is there a way to really include the mixin in the behavior or do I have to convert everything to Mixins and use the mixins in the mixins that need them to make sure they are always there?
Polymer 2 Using the Polymer.MixinBehavior concepts. The mixinBehavior function also mixes in the Legacy APIs, the same as if you extended Polymer.LegacyElement. These APIs are required since since hybrid behaviors depend on them.
Example:
class SampleElement extends Polymer.mixinBehaviors([MyBehavior, MyBehavior2, ... ], Polymer.Element) {
static get is() { return 'sample-element'}
...
}
customElements.define(SampleElement .is, sample);
I have set up a rather large Vuex project with multiple modules.
https://vuex.vuejs.org/en/modules.html
To grab the example of a getter a getter from a search module could be addressed like so:
computed: {
filters() {
return this.$store.state.search.filters;
}
}
Because I need to access the state of the module by referencing the search property in my property chain do I still need to namespace my module?
The documentation states the following:
By default, actions, mutations and getters inside modules are still
registered under the global namespace - this allows multiple modules
to react to the same mutation/action type.
https://vuex.vuejs.org/en/modules.html#namespacing
But if the module is under its own property in the store isn't the only conflict that could happen between modules themselves, which can easily be prevented by a simple naming convention of the files?
What am I missing here?
But if the module is under its own property in the store isn't the only conflict that could happen between modules themselves, which can easily be prevented by a simple naming convention of the files?
No, you misunderstand. The state itself is properly namespaced, but mutations, actions and getters are still collected on a global level so you can e.g. dispatch one Action and several actions from different modules react to it.
That's the default behavior, but the good news is, that there's an option to namespace mutations, actions and getters: "namespaced: true".
it's documented here: https://vuex.vuejs.org/en/modules.html#
Scroll down to the "Namespacing" section.
I am coding my project with golang. I want to design my project like plugin programming but I have confused with golang. My project have data analysis task, I purpose make a folder that contain modules analysis, if I have new modules after, I just need copy it to folder and main application will pass data to the new modules without modified.
Can you help me? Thanks for watching!
Go with it's interfaces is a good choice to build something pluggable.
Interfaces
Interface in Go is a way of types abstraction.
Interfaces in Go provide a way to specify the behavior of an object: if something can do this, then it can be used here.
It means a simple but very powerful thing - you can use different composite literals as an interface type if they implement the interface. This is already a pluggable system and if are looking for something simple it is possible to build with minimal effort.
Simplest implementation
Let's say you have such a primitive architecture:
▾ pluggable/
▾ app/
pusher.go
▾ plugins/
green_button.go
plugin_interface.go
red_button.go
main.go
plugins/plugin_interface.go
An interface which will be used as a type abstraction for plugins.
package plugins
type Button interface {
Push()
}
plugins/green_button.go
Now it is possible to extend your application with plugins implement the interface.
package plugins
import (
"fmt"
)
type GreenButton struct {
Msg string
}
func (b GreenButton) Push() {
fmt.Println(b.Msg)
}
plugins/red_button.go
One more plugin...
package plugins
import (
"fmt"
)
type RedButton struct {
Err error
}
func (b RedButton) Push() {
fmt.Println(b.Err)
}
app/pusher.go
An interface type embedded in the composite literal. Any cl implementing the interface could be used in the Pusher instance. Pusher doesn't care about particular plugin implementation it just pushes. It is well abstracted and encapsulated.
package app
import (
"github.com/I159/pluggable/plugins"
)
type Pusher struct {
plugins.Button
}
main.go
Usage of all the stuff.
package main
import (
"errors"
"github.com/I159/pluggable/app"
"github.com/I159/pluggable/plugins"
)
func main() {
alert_pusher := app.Pusher{plugins.RedButton{Err: errors.New("Alert!")}}
success_pusher := app.Pusher{plugins.GreenButton{Msg: "Well done!"}}
alert_pusher.Push()
success_pusher.Push()
}
You can add more sugar, for example one more level of isolation to use a single button configured to be a one or another particular implementation and so on.
Plugins as libraries
Same trick with plugin-libraries. A composite literals declared in a plugin-libraries must implement a plugin interface of the main application. But in this case you will need a register a function and a file with libs imports, so it already looks like a nano plugin framework.
Go 1.8 has support for plugins: https://beta.golang.org/pkg/plugin/. If you can wait a couple months you could use that (or just use the beta 1.8).
I don't understand.. if I can use import in Aurelia, why do I have to wire up the constructor with #autoinject() and all that? I'm sure I'm missing something, but, from what I can tell, I can just use my imported module whenever I want.
import something from "whatever"
export class SomeViewModel {
activate() {
// use something
}
}
Typically, in an Aurelia application, the thing you are importing isn't an instance of Something it's the class Something. To actually use whatever has been imported, you need an instance of it.
import Something from 'whatever';
let something = new Something();
When you use Aurelia's Dependency Injection system, you are utilizing a design pattern called "Inversion of Control." Instead of your class (or you) being in charge of instantiating its dependencies, it lists what dependencies it has and then has instances of the dependencies injected in to its constructor function.
This helps with testability, as now you can pass mocked instances of the dependencies to a class in your test fixtures (note that in your tests, your tests will pass the mocks to the constructor, and not rely on Aurelia's DI container).This also allows you to tap in to the Dependency Injection container's ability to be configured to create dependencies using different object lifestyles such as singletons and transient.
--- Edits to answer OP's questions from comments ---
If I import a module defined as export default class Something into an
aurelia view model using constructor injection, it does not need to be
instantiated. It is an instance of the class Something.
This is because Aurelia's Dependency Injection container is instantiating an instance for you. This is why your code looks like this:
import {inject} from 'aurelia-framework';
import Something from 'somewhere';
#inject(Something)
export class Foo {
constructor(something) {
this.something = something;
}
//...
}
and not
import Something from 'somewhere';
export class Foo {
constructor(Something) {
this.something = something;
}
//...
}
You are telling Aurelia "I need one of these, please give it to me," and Aurelia says "Sure thing, I've created one or I already had one lying around, here it is."
In other words, it appears that aurelia's constructor DI only works
with class exports, and it does instantiate the class. It looks like
if I want to import something like moment js into my aurelia view
model, I should just continue doing things the way I've always done
them (not using aurelia's DI). Does that sound correct?
This is correct. Libraries like moment give you a function to use, and not a class that can be instantiated by Aurelia. For these you would continue to use them as in the past.
Well technically you can use the imported modules without Aurelia's DI, but in most situations that would be a bad thing. The Dependency Injection layer gives you so much versatility and flexibility. It handles caching, it supports singleton and transient dependencies, handles lifetime and makes thing neater from an architectural perspective.