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 years ago.
Improve this question
I saw this example and wondered why anyone would do it:
function a(str) {
return [
'<div>',
str,
'</div>'
].join('');
}
Isn't it an equivalent to the following code and what's the advantages / disadvantages of using just:
function a(str) {
return '<div>' +
str +
'</div>;
}
Thank you.
They're the same thing. Some experiments have shown using the + operator is faster but this will vary between browsers. Not to mention, these kinds of micro-optimizations don't tend to contribute much.
So which one is better? Whichever one you like the most.
My preference would be to use the "string concatenation" version, in other words, your second one.
They both return the same thing. In the case of the first example however your combining string elements of an array together. In the second one, you're simply adding the strings together.
There's no need to use an array to solve this problem, and the second one is much more concise too. It's a better web development practice.
Performance wise, there will be a slight improvement with the second one. Since it has less space, that means the JavaScript file that loads it will be smaller, taking up fewer resources on a user's browser.
It will also make it more easily maintainable with fewer lines of code.
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 2 years ago.
Improve this question
I was wondering why the following code is problematic to the CRA (and many other) js linter(s) by default. What I see here is a compact readable line of code. My guess is because the one liner below is not very scalable. Sometimes small simple chunks of code won't (shouldn't) need to get any bigger anyway. What other reasons are there to avoid writing simple one liners like this?
doSomething( prev => (prev.searchField = val, { ...prev }) );
Do I really need to do this to make the linter happy or are there other ways to keep the above one-liner?
doSomething(prev => {
prev.searchField = val;
return { ...prev };
});
To keep this succinct Lets not debate what is more readable just please answer why you think the linters warn this type of code with Unexpected use of comma operator no-sequences.
The ESLint rules are very customisable, to allow teams that have specific guidelines to customise the warnings and lintings so that they can begin to use the tool without having to edit all their previous code.
However, CRA and a few others come with recommended linter settings that are generally "best practise" and also prevent beginners making mistakes.
Although you may think that simple one liner is readable, for a lot of people it isn't, and so that no-sequences rule is a part of that pre-selected rule-set that you happen to be using.
If you disagree with the recomendations, then you are able to turn it off easily.
no-sequences rule in EsLint docs
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 3 years ago.
Improve this question
I'm using Typescript for a Node application and I love to fully use the power of Javascript with all the good stuff of Typescript. Line after line I took up the habit to chain functions, to use arrow functions, to user carrying and partial functions and so on.
What I really cannot understand is why the forEach function return void instead of something useful I can use to perform a chainable, just one-line and elegant piece of code.
My question is about the design considerations behind this choice that at first glance seems to be just annoying and the implications a return value can cause.
Because that's what forEach does. It's like a for loop; it isn't meant to evaluate to anything useful. It's intended to be used to carry out side effects using a function. If you need it for anything other than that purpose, it's the wrong tool for the job.
If you want a looping function that evaluates to something, use map or reduce instead. map will return a new list based on the old list, and reduce will return a reduced value from iterating over the list.
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 6 years ago.
Improve this question
I have on several lines of code a conditional like this:
if ( i < DEVICES ) { .... some code
This code is repeated several times in my code, 15 times to be exact.
The thing is that since this is repeated I created a function that replaces the validation:
function isDevice(i) {return i < DEVICES; }
And replaced all my conditionals with the function:
if ( isDevice(i) ) { ... some code
Now I am thinking, even though the code is repeated several times, is it really worth using the function? I am asking because it's more lines of code that I am using to abstract something that is repeated 15 times, but is a very simple validation.
Yes it is. If you had to change something about that condition (e.g. you made a mistake and it has to be
i < DEVICES-1
or something like that.
You don't have to change it 15 times, but only once.
As commented by #str, readability is king. If your program is of any use, it will spend a lot more time being maintained than being developed. So, when in doubt, always code for a future you (or a future colleague) that will have no idea of what you were thinking when you originally wrote the code.
Since i < DEVICES-1 is less readable than isDevice(i), I would vote for using the function.
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
While working on a recent project, I began wondering when somebody may use JavaScript vs. PHP for a generic function. Take this basic function (in JS) as an example, which simply returns whether or not a number falls within a particular range:
function range(num, var1, var2) {
if ((num >= var1) && (num <= var2)) {
return true;
}
else {
return false;
}
}
For something that doesn't query a database, nor is it information that should be — or needs to be — indexed for SEO (I know by default JavaScript will not be indexed), then my inference would be that JavaScript would be sufficient. But at the same time, PHP could be as well.
Basically, if the ONLY point of the application were a simple function like above (not that I can see a reason for that, but I digress...), then which langauge would be better to write this in? JavaScript or PHP?
Would love any insight as to which would be the best method to use and why. I recognize there is no right or wrong answer necessarily, but would like to hear arguments for or against one over the other.
Thanks!
As you point out, there is no necessarily right or wrong answer.
I would say that it depends:
-Is it a problem for people to be able to reverse engineer the code?
-Is it a problem if it does not execute because JavaScript might be disabled?
-Is it preferable to have code execute client-side versus server-side from a performance point of view?
-Does the content generated by the output of this function qualify as something you might want indexed by Search Engines?
Depending on the importance of the above criteria/questions, JavaScript might be disqualified.
From the points above, the common thing seems to be that choosing for JavaScript is more likely to lead to potentially undesirable side-effects.
The safest bet, from what I theorize, is therefore the server-side language, PHP.
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 9 years ago.
Improve this question
What is better to use in javascript to square some value.
Math.pow
Math.pow((circle2.x - circle1.x), 2)
Or my own function
square(circle2.x - circle1.x);
function square(a){
return a*a;
}
It is nearly always better to use a library then write your own code, unless you have a good reason not to. Reasons why:
It saves you work.
It is well-tested code, while your code might introduce bugs.
Someone else who looks at your code will know what Math.pow is, so it makes your code easier to read.
Obviously this is a very simple case, in which your own function is unlikely to cause a problem. Still, it is better to get in the habit of using libraries whenever possible.
By the way, Math.pow performs a lot of handling of special cases. This illustrates that even a simple function can have more pitfalls than it appears at first. By using a library, you don't have to worry about handling all of the edge cases yourself.
You should always prefer to use library functions - what is the point in reinventing the wheel?
Library functions are optimized and may cater for some corner cases you are not aware of...
Are you going to provide own implementation of multiplication as well?
For a power 2 specifically I would use multiplication because you really don't lose any legibility. Even more if speed is important, multiplying will probably be faster than function calls.
edit: I mean don't even create a function... just a*a.