You get an error if you try to call an ES6 class as a function (without 'new'). So just try to do that inside a try-catch. If there is no error you know it is not a class and you have the result of the function already. If you do get an error and you know it is a function you know it must be a class.
How Does React Tell a Class from a Function?
31–40 of 142 posts
Re: How Does React Tell a Class from a Function?
#32Earlier quoted context omitted.
You don't write js because you like, is because is a competitive advantage: - Write in one language only for both client and server side. Why is good? You just need js devs, no need to duplicate validation and other logic. I'm making a game right now and has js on the backend. I want to make the game single player, now I can just import a file from the client side and > now is single player. If your backend is in jav…
I really don't get how JS on the client and the server is any real advantage - besides sharing some syntax, the models and paradigms are so drastically different it might as well be two different languages. Why make the server so bad when you don't have to? I think JS has its place despite it's flaws, but for the sake of sanity I can't imagine ever using it on the backend by choice. If you want the ease of express, u…
[deleted]
Re: How Does React Tell a Class from a Function?
#33You get an error if you try to call an ES6 class as a function (without 'new'). So just try to do that inside a try-catch. If there is no error you know it is not a class and you have the result of the function already. If you do get an error and you know it is a function you know it must be a class.
Classes get transpiled to functions, but even if they wouldnt, what if function body throws?
Re: How Does React Tell a Class from a Function?
#34I'm really quite surprised how much time is spent worrying about Babel. I always thought that you could just write valid JavaScript and it's completely Babel's responsibility not to screw that up. Edit: not sure what's wrong with my comment so let me clarify: I wouldn't have thought that library developers had to think about what other tools might do with their library. I always thought that so long as your code is v…
Transpiling ES6 to ES5 is a hard problem, and I believe it's impossible to be 100% correct unless you ship a full JS interpreter written in JS (which would have terrible performance). As a result, Babel and TypeScript both have to make pragmatic tradeoffs, and you can certainly find plenty of cases of non-spec-compliance if you go looking for them. Sometimes transpilers diverge from the spec for performance reasons, sometimes because following the spec would be too hard to implement, and sometimes because there isn't any (reasonable) way to follow the spec. This is especially true with low-level reflection operations like seeing if something is a class or a function.
Re: How Does React Tell a Class from a Function?
#35Earlier quoted context omitted.
You don't write js because you like, is because is a competitive advantage: - Write in one language only for both client and server side. Why is good? You just need js devs, no need to duplicate validation and other logic. I'm making a game right now and has js on the backend. I want to make the game single player, now I can just import a file from the client side and > now is single player. If your backend is in jav…
I really don't get how JS on the client and the server is any real advantage - besides sharing some syntax, the models and paradigms are so drastically different it might as well be two different languages. Why make the server so bad when you don't have to? I think JS has its place despite it's flaws, but for the sake of sanity I can't imagine ever using it on the backend by choice. If you want the ease of express, u…
The backed's job is to give the frontend what it needs, so at some point it has to make the objects that the fontend will consume and instantiate. That point at which the two realms join is a source of lots of potential reuse, from model objects, to the business rules surrounding their use and structure. Also consider things like validation, javascript-driven server-side rendering, etc
Re: How Does React Tell a Class from a Function?
#36You get an error if you try to call an ES6 class as a function (without 'new'). So just try to do that inside a try-catch. If there is no error you know it is not a class and you have the result of the function already. If you do get an error and you know it is a function you know it must be a class.
I believe throwing and catching exceptions over and over as part of normal rendering is the sort of thing that would be disastrous for performance, certainly the sort of thing that the React authors would really want to avoid.
Re: How Does React Tell a Class from a Function?
#37You get an error if you try to call an ES6 class as a function (without 'new'). So just try to do that inside a try-catch. If there is no error you know it is not a class and you have the result of the function already. If you do get an error and you know it is a function you know it must be a class.
Yikes. Definitely do not do this.
Re: How Does React Tell a Class from a Function?
#38Earlier quoted context omitted.
If you're going to be using any language seriously, you better understand how functions and objects and classes in that language work.
In most cases I'd agree, but essentially JS has gotten to the point that it's only usable if you write an entirely new language on top of it, like React/Vue/Angular have. All of them are basically to avoid the confusion that arises from the weird quirks of JS, like it's classes implementation. These languages then also try to integrate the few positives of JS into their paradigms, and IMO they are decently successful…
I don't understand how "React/Vue/Angular" is considered "an entirely new language." I use React primarily, so I'm going to speak from knowledge of that. It is very obviously a framework and it does one thing - handle your view.
Depending on what you are doing, you may have very little react-specific code in your application.
You have data fetching, caching, persistence, authentication, tons of things, not to mention business logic that needs to be implemented in just plain Javascript.
Then out of that process you may have workers or other async background jobs happening which should not involve React at all.
Re: How Does React Tell a Class from a Function?
#39Earlier quoted context omitted.
You don't write js because you like, is because is a competitive advantage: - Write in one language only for both client and server side. Why is good? You just need js devs, no need to duplicate validation and other logic. I'm making a game right now and has js on the backend. I want to make the game single player, now I can just import a file from the client side and > now is single player. If your backend is in jav…
I really don't get how JS on the client and the server is any real advantage - besides sharing some syntax, the models and paradigms are so drastically different it might as well be two different languages. Why make the server so bad when you don't have to? I think JS has its place despite it's flaws, but for the sake of sanity I can't imagine ever using it on the backend by choice. If you want the ease of express, u…
> I really don't get how JS on the client and the server is any real advantage
from my own experience, using single language has huge influence on overall code quality. Makes you understand it much better, comparing to situation you must switch between multiple languages. As you gain more experience in it, the less obvious bugs you'll make (just by knowing what's good and what's wrong).
The worst js code I see, is coming from programmers for whose javascript is their secondary (or third) language. They simply don't understand the basics of it. For example they use timeouts to make asynchronous code synchronous, etc... Then bitching on internet how bad language it is.
Re: How Does React Tell a Class from a Function?
#40I have written maybe 200 lines of JavaScript in my life, and this article has strongly reinforced my desire to never have to write a single one more. The next time someone asks me what the problem with JavaScript is, I will send them this article. "Scheme for the browser" what a joke. Some excerpts for those that didn't have the strength to sit through the entire thing without pulling their hair out: > If you called…
I don't understand why you're getting downvoted, completely agree.
I'm hoping WebASM can save the browser from this foul language. Don't even get me started on server-side JS; if it were a nice, sane scripting language, I'd agree, but the amount of hoops, translators, hackish dev tools etc that have been thrown into the mix to wrangle it into a workable experience... it's too much.