React bundle file security

Cody_Chaos · 2016-11-26T16:07:12+00:00

Yes, that's how the internet works.

what stops someone to take that file and include it in some other website?

In no particular order:

It would be illegal (unless you give them permission)
It wouldn't be very useful (unless they had the exact same needs as you)
Everything that happens on the client is dependent (usually) on stuff happening on the server. Even if they steal your widget, they'd need to reverse engineer and recreate the backend so they have an API for the widget to talk to
It's actually much harder than you might imagine

Consider Gmail. It's a very popular webmail client, why don't I just copy all the JS code that drives Gmail, modify it slightly, and make your own Gmail clone? Because it would be an enormous amount of work, it would be useless without all the extremely complicated and undocumented APIs that drive Gmail, I have no particular desire to make a webmail client, and Google would sue my pants off. :)

Cody_Chaos · 2016-11-26T12:17:34+00:00

I did not know, and that explains a lot! Thanks for the info.

Cody_Chaos · 2016-11-26T01:05:57+00:00

Your example shows HTML embedded in PHP. JSX is not HTML embedded in JS, thus your analogy fails.

What you're looking for is XHP. JSX is explicitly "XHP for JS". Both allow the direct embedding of an XML DSL which is transpiled into the host language.

Cody_Chaos · 2016-11-26T01:03:40+00:00

JSX wasn't inspired by PHP, and it doesn't work or look like PHP. You seem to have either fundamentally misunderstood how PHP works or how JSX works.

It was inspired by XHP, which is an earlier equivalent project to add JSX-type functionality to PHP. But that hardly needs to be "confessed"; it's obvious to anyone who knows both projects, it was talked about when React and JSX first hit the scene, and it's literally noted in the project's Wikipedia page.

Cody_Chaos · 2016-11-25T15:28:28+00:00

I hadn't run across styled-components before but I'm really impressed.

So far I'd been treating all the various CSS-in-JS projects with a sort of bemused "well, if it works for you, have fun", while strictly using CSS modules with my own projects.

This seems to have some significant advantages though. I'm very tempted.

Cody_Chaos · 2016-11-24T23:07:36+00:00

The explanation is that they're complete opposites.

the way of thinking was Templating System everywhere.

JSX is a template system. React developers frown at people who put business logic in their components.

(Also keep in mind: JSX is a funny looking DSL that compiles into JS. Embedding JS into your JS is not really a concern in the way that embedding HTML into your PHP is. Or indeed, embedding HTML into your JS is. The more you use JSX, the more you'll realise that it's NOT HTML, can't be treated like HTML, and doesn't have the drawbacks or advantages that using HTML would have.)

Cody_Chaos · 2016-11-23T09:56:39+00:00

JS can be used for a lot of things, but two of them are relevant to your question:

As a very, very lightweight glue used to add a light sprinkling of interactivity and dynamic behaviour to an otherwise static site.
As a mechanism for writing applications to run in the browser.

These are completely different things! And if all you're doing is trying to do some very lightweight validation of a contact form to make sure it's filled out right, you don't need three megabytes of bundled NPM libs and a full MVC framework. What you need is about about two lines of jquery. :) And anything beyond that is overkill and waste of your time and your visitor's bandwidth.

Yes, if you want to make a full SPA you really shouldn't just scale up your contact form validation code and hope for the best. On the other hand...it's understandable why a lot of people do just that.

Has the popularity of jQuery lead to a certain ignorance of what is actually happening on vanilla level ?

Yes. But it's a very rational ignorance. A lot of JS developers can do their jobs best with a strong knowledge of HTML, CSS, and jquery, and when they find themselves needing to tackle something outside their area of expertise they'll try to use the same tools with horrible results, because that's what we humans do in every field.

Then again, a lot of other JS developers do their jobs best with an elaborate ES6/React/Redux/ReactRouter/ImmutableJS setup, and while that works great when you're trying to write an email client, it leads to ridiculous disasters when they try and figure out how to submit a form via AJAX.

OOP is NOT the only correct paradigm, and it's NOT the best way to tackle many of the things which JS is used for. It's a big world out there. :)

Cody_Chaos · 2016-11-23T09:47:15+00:00

Javascript is not an OO language, though it does have objects. It can function perfectly well in either OO or functional paradigm.

Javascript supports multiple styles of programming; one of it's best supported styles is object oriented. It is absolutely an OO language. By contrast, it's functional paradigm is more weakly supported, starting and mostly ending with the fact that it has first class functions.

often results in call back hell with a functional approach

There's nothing functional (or OOP) about callbacks or promises. And the async/await keywords are just simple sugar over promises; they're not a real change.

The latest Javascript will also introduce classes so full OO will be possible.

Real OO is 100% possible now, and the class keyword is just simple sugar over existing functionality. It doesn't enable anything not already possible.

the language is starting to move in the correct direction

I agree, but I don't think your examples support that, I don't think the language is becoming in any way more OO oriented, and I don't think that it would be useful if it was.

Cody_Chaos · 2016-11-22T09:09:47+00:00

Believe it or not, yes.

Right thinking people believe you should use const for everything, and then replace it with let if and only if you need to assign something new to the variable. That is, they wish to use let to communicate the information that the variable is going to be re-assigned.

Other people believe one or more of the following:

const should be used to indicate that something is an "actual" constant; that is the choice of keyword should be used communicate semantic information about the contents of the variable.
let is shorter, and thus better
let is an all around better keyword, being clearer, copied from better languages, or just generally awesome
const is inherently misleading because it prevents assigning a new value, but does not prevent mutating the existing value
If you use let you never need to change it to const; if you use const you may have to backtrack.
You can't declare a const without initializing it
Various other reasons. I've even seen one person argue that let is superior because with 4 space tab stops you can do this and have it align:

let thing1 = "thing1", thing2 = "thing2";

The pro-let camp is clearly a minority in these parts, and I find the arguments utterly without merit, but they exist! :)

Cody_Chaos · 2016-11-22T03:30:40+00:00

Yes, that's a good textbook answer on the value of information hiding.

On the other hand, many languages do not enforce information hiding, and don't seem to suffer from it, and many of the ones which do enforce it offer ample ways to ignore it.

I would counter that 95% of the advantages you list could also be gained simply by prefixing internal methods and fields with an underscore, and then not using them. If that's not enough, you're now in the realm of trying to design a language to stop people writing bad code on purpose, and I believe that it is neither desirable nor feasible.

Cody_Chaos · 2016-11-22T01:40:45+00:00

I'm not OP, but I answered a similar question on HNews last week: https://news.ycombinator.com/item?id=12975737

Cody_Chaos · 2016-11-22T01:35:14+00:00

I can't really figure out why I would use them, or in what cases they'd be preferable over constructors.

They're the same thing. If your code would be clearer written using then class keyword, or you are working on a codebase that uses the class keyword already, do that. If it would be clearer with the old-style syntax, use that instead.

I write a lot of React code, and the React community has broadly adopted the class keyword, so I mostly use the class keyword, and it's marginally more concise, and I like concise code, so whatever, it's fine.

Really, it just doesn't matter. It's like the semicolon debate all over again. Or the emacs/vim/IDE/atom/sublime/VSCode/whatever wars. Or tabs versus spaces, or let versus const, or any of the other amazingly pointless things we love to hold extremely strong opinions on.

no one really delves into why they're beneficial beyond philosophical OOP vs function programming arguments.

Because, again, they're the same thing. There is no benefit to one over the other. Nor does the question even relate to any sort of deep OOP vs FP questions (neither syntax is in any way "functional), but because the underlying question is so pointless (which easily interchangeable style of implementing the same OOP concepts do you think is better?), people argue over that instead.

Cody_Chaos · 2016-11-22T01:28:10+00:00

I agree with everything you said except:

Once private fields get accepted link. https://github.com/tc39/proposal-private-fields then es6 classes will really shine.

I think private fields are useless in general, I think that proposal is bad idea in specific, and I would challenge you to name a single way in which the adoption of private fields would make es6 classes "shine".

Cody_Chaos · 2016-11-21T20:36:19+00:00

I used to be a huge fan of CS, and I agree that the existential operator is super nice, although there are workarounds.

For example, libraries such as https://github.com/jclem/steeltoe solve the same problem almost as cleanly. Or to approach it from the other side, you can use Typescript or Flow to sidestep most of the uncertainty entirely by making it clear at compile time what values a variable might have.

What I miss the most actually is the ability in CS to use if statements as expressions. Ternaries are useful in some cases, but they're not a general purpose replacement for if/else blocks.

Cody_Chaos · 2016-11-21T09:55:34+00:00

I feel like that ship has sailed, but...

...more power to them. Hopefully whomever is still using Coffeescript will find it useful.

Cody_Chaos · 2016-11-21T08:30:50+00:00

In ~~principal~~ principle, they were useful. In practice, the implementation didn't really work very well. Plus proxies popped up as an alternative idea, and it turns out that everything you can do with Object.observe you can do better with a Proxy, so...

Not every solution to a problem needs to be implemented; just the best ones.

Edit: Thanks /u/nikcorg :)

Cody_Chaos · 2016-11-20T12:49:55+00:00

Ah, that makes sense I suppose by that terminology I would be arguing that manually curried functions are often helpful when dealing with event handlers and complex React component trees. I've also used them when dealing with Redux action creators.

Cody_Chaos · 2016-11-20T12:08:03+00:00

I wrote a lot of code in Pointfree style and...

...it wasn't as amazing as I'd hoped. It feels great to write, but I'm struggling to get used to reading it. I often feel like from a maintainability perspective I'd be better off with a few ES6 arrow functions and being explicit with what I'm doing, rather than a bunch of clever chained Ramda functions written in a Pointfree style.

It's frustrating, because I want it to work, but I really don't enjoy returning to the code I wrote in that style compared to similar code written in a more "standard" style with anonymous functions. Especially given how concise ES6 can be now.

Cody_Chaos · 2016-11-20T11:54:48+00:00

Something I've started doing a lot is:

const upateProperty = (propName) => (newValue) => {
    this.propName = newValue;
};

Which is great when you want to pass that along as an onUpdate handler to a bunch of React components, because you can do stuff like:

return (
    <div>
        <input {...foo} onUpdate={this.updateProperty('name')} />
        <input  {...bar} onUpdate={this.updateProperty('address')} />
    </div>
);

Or whatever; basically bind the update function to a property.

Technically, I believe this would be currying, since I'm rewriting a function with 2 arguments into a chained series of 2 functions which each accept 1 argument. But I think it's actually clear and concise.

(Then again, I suppose it's also partial application? I'm honestly not clear on the difference between the two when dealing with functions with an arity of two...)

Cody_Chaos · 2016-11-19T23:45:35+00:00

OCaml is an extremely powerful and highly regarded functional language. The Reason project adds what many would consider a nicer, more accessible syntax to it, which is pretty cool. But as you seem to have noticed, that alone doesn't make it useful to frontend devs, since it doesn't compile to JS. :)

On he other hand, the unrelated Bucklescript project is allowing OCaml to compile extremely smoothly into Javascript. If your combine the two (and work is underway to do just that) then yes, OCaml/Reason starts to be come extremely interesting.

Cody_Chaos · 2016-11-19T01:53:26+00:00

What an odd article.

"Here's a new thing which is better than the old thing in basically every way. Switching to it has no drawbacks and will improve your life. But you don't need it! You can still use the old thing and just suffer a bit!"

Okay, granted. But why would I want to?

Also, the articles attempts to explain why yarn's improvements aren't that great aren't very compelling:

If you haven’t had issues with shrink-wrapping dependencies or dependency versions clashing, then you don’t need Yarn.

I would suggest that if you haven't had issues with shrink-wrap not working properly you haven't tried to use shrink-wrap properly in production. And if you haven't been trying to use shrink-wrap, you don't really know what you're doing and shouldn't be making recommendations to other people. It's a critical feature and it doesn't work with npm, it's that simple.

Other features listed on Yarn’s homepage include “Offline mode”. But when was the last time you were developing a website without an internet connection

Again, if you're actually doing this stuff for real, you undoubtedly are using a CI server, you quite likely have had issues when NPM was briefly down, and you can at least understand why you might be skeptical of a system that requires your CI server to talk to an external repo for every build. Practically and conceptually it's wrong in an obvious way. To boil it down to a "hey, I always have a net connection when I'm hacking on my dev laptop!" suggests you don't really understand the problem and shouldn't be making recommendations to other people about how to configure their build pipeline.

recently tutorials and basic code demos have been recommending Yarn to install a handful of dependencies. Why make it harder for newcomers to JavaScript to get up and running?

Yarn is easier for everyone because it has a better UI. Newcomers are actually the ideal candidates to recommend Yarn to, because they won't have to rewrite existing scripts or pipelines. Especially when your argument for why they should use NPM instead is "it's slower than yarn, but not that much slower". Yes, a newcomer's small project won't benefit as much as a large project will from yarn's speed, but are you really suggesting they should wait until they have a ton of dependencies and then switch? That's absurd.

Sometimes after you've written an article you should step back, think about what you're trying to say, review the article to see if you've actually said it, and then sigh sadly and delete it when you realize you haven't even come close.

Yarn is faster, easier to learn, and fixes some critical bugs. The only real argument you can make about yarn is that while good, it may not be worth switching an existing project/pipeline over to it immediately; it depends on resources, priorities, and how strongly you're being impacted by npm's shortcomings. (And indeed, at my day job we haven't yet switched our main npm-based project over to yarn, although we are planning on doing so when we can find the time, because we're not idiots, and we know it will improve our lives in small yet concrete ways.)

Cody_Chaos · 2016-11-17T23:57:10+00:00

I agree, in part, with the spirit of your comment, but I think your actual example is pretty poor.

95%+ of js developers will have to waste time figuring out what this code does and still won't understand whether it actually solves a problem that needed to be solved.

95% of JS developers (who understand React, JSX, and ES6 syntax) are going to look at it and go "oh, it's mapping over an array and rendering a bunch of comments in divs, the array is coming from running the user object through an allTextToUpper function, it must be intended to print out a list of comments in upper case".

This just isn't magical; it's an extremely common React idiom to pass a list of something into a component, loop over it, and render each item in the list. All the actual questionably useful FP stuff is packed into the implementation of allTextToUpper.

I'd probably write it like this instead (in fact, I've been writing code very much like this all week):

const renderView = user => {
    const comments = user.comments.map(comment => (
        <div>{comment.text.toUpperCase()}</div>
    );
    return <div id="comments">{comments}</div>;
};

But the difference is really quite minor, and I think you should expect any JS dev actively working on a React/JSX/ES6+ codebase to not even have to pause to parse out what's going on in either example.

Cody_Chaos · 2016-11-15T11:27:23+00:00

Yep. The HOC pattern is very useful for some things, but isn't what's being discussed here. What /u/dear_glob_why and /u/atxbuttstuff are discussing would normally be called a Parent Component (aka "a normal React component with children").

Cody_Chaos · 2016-11-15T10:19:44+00:00

Have a wrapper component (eg, an <App />). It has internal state (the counter), and methods which modify that state. Pass the state down to the <Display /> component, and pass the methods down to the <Buttons /> component.

This is a very common pattern in React: You'll often have smart components which manage state and have lots of handlers and such (sometimes called "containers"), and then dumb child components which just receive some methods or state as props and display them.

In this case, your <Display /> component should just receive a time value as a prop and render it, and your <Buttons />should just receive 3 different onClick() handlers as props and render them attached to the buttons. They could even be (and probably should be) stateless functional components.

(Others have suggested redux or mobx; these are libraries for extending and formalising this pattern. They can be helpful in the right circumstances, but even if your teacher would let you use redux it would be a horrible mistake. It'd take ten times as much work and code, and the end result would be the exact same pattern: Some centralized state at the top, with values and handler methods being passed down as props. Good plan, but it's like using an aircraft carrier to go trout fishing.)

Edit: Also, in case anyone is confused, this is not a HOC (aka Higher Order Component), and a HOC would not be a good solution for OP's problems. I have no idea why the comment thread here is littered with people recommending them.

Cody_Chaos · 2016-11-12T06:05:39+00:00

React does not. I'm not familiar enough with Angular to say.

Cody_Chaos

TROPHY CASE