Reading some vuejs 3 with Composition API docs I see 2 possible way of vars declaring, like
const var_name = ref('')
or
let var_name = ref('')
and looks like var declared with “const” can be modified(say getting data with axios request).
I do not see any errors when I use similar code inb my app.
Are these declarations the same? Which way is preferable?
I think an article like this is still the best way to go here: https://www.freecodecamp.org/news/var-let-and-const-whats-the-difference/
As of what is recommended, usually use const and if you need to redefine something else on top of it, use let. Of course, non primitive types (like Objects) can be mutated, it being out of the const scope redefinition.
TLDR: this is more of a JS vanilla question and have nothing to do with Vue or Composition API in particular.
Related
I'm working on unit testing all of my components, and I've hit a bit of a snag (or maybe a misunderstanding of how to properly test).
I have a component that receives some parameters from the store, and then calls a series of functions that mostly return an input string with some transformations applied.
This looks something like the following:
<script setup lang="ts">
import { someTextTransform } from '../utilities/someTextTransform';
...
let parsedText = store.input;
if (store.applySomeTextTransform) {
parsedText = someTextTransform(parsedText);
}
I have already tested these functions themselves, so to me it seems like testing the actual output of the calls is unnecessary and I instead could just test to see if the functions have been called.
Here is a snippet on spying from the Vitest docs
Mocking functions can be split up into two different categories; spying & mocking.
Sometimes all you need is to validate whether or not a specific function has been called (and possibly which arguments were passed). In these cases a spy would be all we need which you can use directly with vi.spyOn().
This is exactly what I want. I want only to know whether or not the function has been called. The functions themselves are simple enough that they do not require additional setup (i.e., mocking is not required).
However looking through the docs of Vue Test Utils I don't see a way to do this. It looks like a more common way to do this is to mock the functions first and then you can spy on them more easily, but then I would have to create mocks that don't actually mock the functions which seems like I'm adding code to my codebase for no benefit other than a weird workaround.
I may just be missing something on how to do this, but I might also be approaching the testing in a suboptimal way so any advice is appreciated.
I am getting start to study Context API of the React Native.
I understand that the Context API is to solve the problem to send a lot of props in the parameters.
It seems to me as a global variable.
In this case, to use a static variable of a class in JS don't fix the problem of a variable global?
Why use Context API when we can use a static variable?
What are better in Context API?
Are others API that use Context API in React Native as pre-requisite?
In my experience you can do exactly as you're describing...
You'd set a static property App.instance = this in App's constructor.
Your App class has static methods which can access App.instance.state and App.instance.setState().
I'm curious why this approach isn't mentioned anywhere. Possibly because you can't use static properties in functional components, so it's a bit unfashionable. And it feels like it goes against react's component tree structure.
There is also the general feeling that statics are evil.
I know that there are already some threads about that, but I was not able to find an actual one.
So my question is, should I always use the bind approach or the arrow functions?
What are the pros/cons of them in 2020? From what I read I know, that (at least in 2018) the bind methods had a better performance.
Another question: Should I just bind the functions, which I call use in the render method via a click?
Here a small example
constructor(super) {
props(super)
this.firstBind = this.firstBind.bind(this);
this.secondBind = this.secondBind.bind(this;
}
render() {
return (
<Button title="First Bind" onClick={this.firstBind} />
<Button title="First arrow" onClick={this.firstArrow} />
)
}
firstArrow = () => {
//some outout
}
secondArrow = async() => {
//fetch some data from a database and output it
}
secondBind() {
//some output
}
async secondBind() {
//fetch some data from a database and output it
}
My goal is to understand it completely.
Thanks a lot!
Jan
You are right, this question has been asked many times before and it will likely be closed because it has so many duplicates, but I will provide a short answer anyways.
Bind and arrow functions achieve the same in a React component
On a more technical level binded functions and arrow functions are different, but for the react world which you are talking about, they are the same, the simply create a function which is bound to the context of the instance that created them, so you can access the instance variables when they execute.
But why then is there two ways to create binded functions?
Why then, would you ask, go through the trouble of having two ways of creating context-binded functions? well, even though they achieve the same you can tell that that the .bind version is more verbose and also prone to error, as you might forget to bind the functions on the constructor, therefore it is considered good practice to use arrow functions.
The react team did not create them, they are a part of javascript and having to bind functions is just a consequence of the underlaying design of the language, React only forces you to bend javascript to properly work as an OOP language.
Ok, so what should you do?
That being said, the react ecosystem is moving towards hooks, and even though the team responsible for react keep repeating one does not need to use hooks, the tendency is clear, class components will disappear, ex: as libraries update to use hooks and maintaining to different ways of accessing them is too much trouble, most of them use hooks only.
So TL:DR in 2020: this question is no longer relevant, go use functional components with hooks and you will have no problems
When using m.module, I often would like to provide arguments to the controller constructor so that the first rendering starts with the right data. However, the Mithril documentation and examples always show module.controller() and module.vm.init() without parameters.
To go around this issue and have module.controller(initData) I've resorted to use this small utility function to wrap and extend the existing m.Module:
var mModule = function (dom, mod, arg) {
return m.module(dom, {
view: mod.view,
controller: mod.controller.bind(mod.controller,arg)
});
};
Questions:
Is this an anti-pattern? Is there an alternate recommended way instantiate the module with custom external data?
Would this cause issues with m.route? I saw some mentions of recursive calls in the source code but could not get my head around it.
Following the 2 points above, is the lack of parameter for m.module a deliberate design choice?
Oh...and thanks to all involved for the existing documentation and discussions.
No, it's not an anti-pattern, and it's an idea that is explored in one of the blog articles, and also by Moria (a router extension library for Mithril)
I'm trying to clear something up that I'm not getting from the dojo docs.
When I create a dojo provide I assume this is like creating a namespace with objects. For example.
myApp = { container: {} }
Written in dojo provide would be:
dojo.provide('myApp.container');
Now I have read somewhere where this is a global. Not sure I get that as its a namespace or are people true in saying this.
Another issue I'm having is if I use a declare to create a class do I need to use provide to create that namespace for me. for example
myClass.js file
dojo.provide('myApp.myClass');
dojo.declare("myApp.myClass", null, {
constructor: function(){
console.log("myApp.myClass created");
}
});
Now if there is truth to provide causing global variables then would this not be a global class now.
When I do a console.log from my app.js file which is my main.js file its not showing as a global but in fact as namespace myApp.myClass.
So can someone clear this up as its a little strange if there is truth in it.
Firstly, to clarify the term "global", technically myApp is a global - it is a variable on the browser's window object. While yes, ultimately the object/class your module defines is contained within that global object (and thus "namespaced" under it), that top level namespace itself manifests as a global variable; it is accessible to any script in the page/app.
Now, onto the declare question. Assuming this code is going into its own module to be loaded via dojo.require, yes, you still need the dojo.provide. While one purpose of dojo.provide is to ensure the variable you will be populating (e.g. myApp.MyClass) and any parent namespaces exist up-front, its other purpose is basically to act like an ACK to dojo.require's SYN - i.e., "yes, you asked for myApp.MyClass, and that's who I am." I'm pretty sure you would find that in the absence of that dojo.provide, dojo.require("myApp.MyClass") would fail, thinking it never found the module it was looking for.
Hope that answers your questions.