Tag Info

New answers tagged

0

I could be wrong, but implementing document.write overwrites anything that the DOM has. Since it's good practice to put JavaScript files at the end of the body, I propose the following method based on previous answers: <script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script> <script ...


4

You've outlined the pros of doing the app client side only. Here are some possible cons - if any or all of them apply, consider shifting to a server based solution: Performance. Would a client based solution be noticeably slower than a server-based one (including traffic)? Javascript is fast nowadays, but a computationally expensive algorithm might require ...


1

I understand that in React state should only contain data which may change and cannot be computed from elsewhere, I think there is no need to store something that cannot change in a variable at all (use constants for that). And if something can be computed from elsewhere, you might wrap calculation into a function and call it when you need. So, this ...


0

When you create an object with the new keyword, you have access to the this object which represents the "public" view of the object. Inside the scope of the function you also can create local variables which are then in the "private" scope. When you assign a function to a field of this and implement that function in the same scope, it can access any of your ...


0

Generally you don't keep them in sync in that way unless there is a reason to do so. Your entire premise is flawed. Most of the domain logic in an SPA, like any application, should be in the server. Only logic pertaining to the user interface should be in the client. Edit: So just to be clear on terminology. I assume that when you say "domain logic" you ...


4

It sounds like you aren't understanding how promises are used. You return a promise. Then, later when your code resolves the promise, it resolves it with a result and that result is passed to the .then() handler attached to the promise: MovieLibrary.getGenres = function() { var promise = new Promise(function(resolve, reject) { /* missing ...


4

Server side relational databases are great for being a normalised primary data store. However, in many cases: Persistent data storage isn't required because the data can easily be recalculated or retrieved again It adds too much latency to make a minimum ~50ms HTTP request every time you want to access the data Making frequent requests to data which is ...


-1

As a 20+ years programmer i am surprised HTML/php programming is so weak in how a user can use inspect element to change a value e.g product id before submitting. My solution is to use java script variables and only use HTML such as textboxes to inform the user of my intentions. eg declare variables in a global space i.e outside of a function. Example ...


0

JavaScript hasn't needed semi-colons to terminate statements in over a decade. That's because newline characters are considered statement terminators(I believe this is also mentioned in early ECMAScript specs). It really makes a lot of sense, especially since there really is no good reason [that I know of] why JavaScript would need frequent use of ...


0

There are good reasons to keep them in. They are not really optional, JS can add them back in with automatic semicolon insertion when they are missing but that is not the same thing. Douglas Crockford's JavaScript: The Good Parts says on two separate occasions that it is a bad idea. The automatic semicolon insertion can hide bugs in your program and ...


0

Quite an old question, however I'm surprised no one has mentioned: Minification: If you happen to minify a JavaScript snippet that doesn't explicitly end the statements with a semi-colon character, you might end up having a hard time trying to figure out what is wrong with a snippet that was just working before the minification and now doesn't work. ...


0

Javascript is adopting the Python style of scripting. Largely, the semicolons are unneccessary. It is just redundancy. The only time semi-colons are really required is when having several different statements on the same line, which rarely comes as a requirement. Instead, as you must have noticed your daily coding, most of your statements occupy a line of ...


0

I don’t leave them out, but i change the rules when to insert them. The rules most people use is Before each line ending Except the line ends with a } coming from a function statement But only a function statement, not assignment to a function literal My rule is: At the beginning of every single line starting with a opening brace/bracket. Mine is ...


6

There is no theoretical limit to how deep JSON objects can be nested, but there usually is a practical limit based on the decoder being used. For example, PHP's json_decode() has a default limit of 512 levels, though it can be adjusted. Read the documentation for the code using the JSON to determine the max depth. If your JSON is actually hitting depth ...


2

Most of the big JavaScript frameworks tend to include the following features: Ajax API Event manager/listeners Promises Class system DOM widgets Templating My recommendation is to study and implement each of these concepts. As you work through them, you'll find that most of them tie together on some fundamental level. Ajax and Promises work well ...


1

This question probably doesn't belong to programmers but var request = function() { return new Promise(function(resolve, reject) { ... resolve(data); ... reject(err); } }; Is of course much slower than var request = promisify(function(callback) { ... callback(null, data); ... callback(err); }); However, ...


7

Bluebird author here. The accepted answer is wrong. V8 promises implementation is written in JavaScript not C. All JavaScript (including V8's own) is compiled to native code. Additionally user written JavaScript is optimized, if possible (and worth it), before compiled to native code. Promises implementation is something that would not benefit much or at ...


0

It's better to use event handlers. Event handlers keep JavaScript out of your HTML which is usually better for decoupling reasons. The only time in-line JavaScript is okay is if you inject it via a template. This is often done when with React.js because it generates a lot of HTML (which is arguably a template).


0

This is an absolutely sensible use of promises. Its one of the primary ways that promises are intended to be used. The way that promises can have .then() added before or after being resolved is directly to allow this kind of usage. The point is that you might have the value right away, or it might not show up until some time later. In either case, the ...


0

Well, calling a time intensive function within asynchronous flow is not acceptable because that blocks everything until it returns. That's the fundamental performance problem with cooperative multi-tasking. Secondly, be sure to test possible flows with your actual promise library. Specifically test what happens if the promise is returned twice, and starts ...


0

JavaScript is a bit special in that variables can be functions and such, but consider in C#, Java or another similar C style language: const public void DoSomething() The const is odd, and that's because method declarations in these languages cannot change, once they're compiled into something else, that is what they do, no matter what (ignoring some ...


40

My reply here is not javascript-specific. As a rule of thumb in any language that lets me do so in a semi-easy way I'd say always use const/final/readonly/whatever it is called in your language whenever possible. The reason is simple, it's much easier to reason about code when it is dead obvious what can change and what cannot change. And in addition to ...


0

We did this at my current company, and we're very happy with the results. Our expressions are written in js, and we even use them to restrict the results the users can get from querying ElasticSearch. The trick is making sure that enough info is available to make the decision, so that you can really write whatever perms you want without code changes, but ...


1

Assuming the language is dynamically typed, I can see two different ways this could be handled without knowing at compile time if a call is async. One approach would be to assume every call could be async. However, this would be incredibly inefficient and produce a lot of extra code. This is essentially what you are doing in option 2. Another option is to ...


2

JavaScript does not have any I/O at all, and thus the question whether or not it is "failsafe" doesn't make sense.


2

Javascript is indeed a fail-safe language, since it also raises exceptions in case of an error (like Java or Python). However, the specific language is not included in this list, because this list refers to fail-safe programming languages taking into account the occasions of errors in I/O operations and system calls. Javascript has been a client-side ...


5

It depends on what kind of I/O you're after. I think that table is primarily looking at system calls, and the stdin/stdout interface to a console windows or terminal. System calls simply don't exist in Javascript, and there's no stdin/stdout-style console window either, so I assume that's why it's not listed (though you can make a case for node.js here). ...


5

The usual solution in this situation is to have a selected class that defines the style of a button that represents the current page - i.e. a different color for the bottom border. When the current page changes, use JS to remove the selected class from all buttons and add it to the one that was just clicked.


0

Take a look on Promises/A+ https://promisesaplus.com/. Nice implementation of Promises/A+ instead of coming ecma6 native support is https://github.com/tildeio/rsvp.js/


1

JavaScript does not support parameter defaults for function declarations. function foo(x) { console.log(x); } foo(); // outputs undefined You would have to add extra code per parameter to set the default value. function foo(x) { if(typeof x === 'undefined') { x = 0; } console.log(x); } foo(); // outputs 0 This becomes a pain when there ...


1

One way to fight the large amount of parameters is a builder pattern + fluid interface. Consider: widget = makeWidget(100, 200) .withSize(384, 256) .withColors(foreground, background) .withBorder('solid', 'black', 1) .withDialogButtons('OK', 'Cancel', 'Help') This approach groups related sets of parameters so that each ...


5

I would say it depends of the language. In a strongly typed language like Java, pasing a Map<String, Object> means that you risk using the wrong type for a parameter. That said, I have seen this been used in frameworks like ExtJS and, for some tasks that require lots of parameters (like initialization, configuration) it is worth it. It actually helps, ...


2

XACML is the solution you are really looking for. It is a type of rules engine that is focused on access control only. XACML, a standard defined by OASIS, defines three parts: an architecture a policy language (which is really what you want) a request / response scheme (how you ask for an authorization decision). The architecture is as follows: the ...


0

React is focused on using plain html. That is why you can just type HTML tags inside your react code. The idea is to keep it simple. Simple answer is: Yes, you should write a lot of plain HTML. When you need to program some piece to use it inside React, then define it on ReactJS. I believe a greate rule of thumb is: When in doubt, think what will be ...


6

In ECMAScript 5, yield is a strict-mode "Future Reserved Word": 7.6.1.2 Future Reserved Words The following words are used as keywords in proposed extensions and are therefore reserved to allow for the possibility of future adoption of those extensions. ... class enum extends super const export import The following tokens are also ...


-4

If you create objects with new you can access your prototype with <object>.constructor.prototype If you use Object.Create you no longer have this (unless you add it yourself) and that is why Object.getPrototypeOf(obj) was added. So there always was a way to get the prototype: when getPrototype didn't exist Object.Create didn't exist either.


0

This is really a question about what went through Eich's mind when he designed the language, so it's only really him who can answer. But if I should venture a guess, I would say the initial version of JavaScript was a quick-and-dirty prototype and he expected to be able to iron out inconsistencies and missing features in subsequent releases. But then it was ...



Top 50 recent answers are included