Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

Thanks for the examples guys, is there a "standard" way to do it or is it the wild west? Also is using higher scope variables a bad idea?

# ? Aug 11, 2015 21:15

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 17:26

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Knifegrab posted:

Thanks for the examples guys, is there a "standard" way to do it or is it the wild west? Also is using higher scope variables a bad idea?

Globals are a bad idea in any programming language, but it really depends on the specific context (heh) of what "higher scope variables" means here.

# ? Aug 11, 2015 21:48

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

Vulture Culture posted:

There's a few other (simpler) ways you can do this.

Using bind():
code:
function1()
    .then(function2.bind(this, 'someArg', 9000))
    .then(function3)
    .done();
Using anonymous functions:
code:
function1()
    .then(function () {
        return function2('someArg', 9000);
    })
    .then(function3)
    .done();

I enjoy the structure of using the latter anonymous function but I have found that it screws up my ability to catch errors.

Where before if I was using globals and I had this structure:

code:

function1()
.then(function2)
.then(success)
.fail(fail);

if function1 or function2 threw rejections in theirpromise, it would skip success and invoke fail.

However using the anonymous method to pass parameters like so:

code:

function1(param1)
.then(function (param2) {
    function2(param2);
})
.then(success)
.fail(fail);

However in this structure, only if there is a rejection in function1 will it invoke fail, if there is a rejection in function2, it will invoke success. Any ideas how to rectify this?

Edit: Leaving this here for anyone else who runs into a similar really dumb problem. I solved it, I wasn't returning the function inside the anonymous function so it was never passing the promise. This is the proper structure for passing parameters in an anonymous function and retaining good rejection bubbling:

code:

function1(param1)
.then(function (param2) {
    return function2(param2);
})
.then(success)
.fail(fail);

Knifegrab fucked around with this message at 00:05 on Aug 12, 2015

# ? Aug 11, 2015 23:41

Ghost of Reagan Past: Oct 7, 2003; rock and roll fun

I'm generating an image serverside, and need to refresh it on the page whenever a new version is generated. It's some pretty simple JQuery that takes some data from the page, passes it off to the Flask server which does the complicated data operations and math needed to generate the image and outputs it to a preset file location. I tried using .attr('src', 'IMAGEFILE'), and I've tried removing the src attribute and then readd it, and it doesn't reload the image. If I reload the whole page the image, since it's been generated, appears.

I don't know much about JQuery at this point so I'm mostly lost.

# ? Aug 12, 2015 02:08

obstipator: Nov 8, 2009; by FactsAreUseless

Ghost of Reagan Past posted:

I'm generating an image serverside, and need to refresh it on the page whenever a new version is generated. It's some pretty simple JQuery that takes some data from the page, passes it off to the Flask server which does the complicated data operations and math needed to generate the image and outputs it to a preset file location. I tried using .attr('src', 'IMAGEFILE'), and I've tried removing the src attribute and then readd it, and it doesn't reload the image. If I reload the whole page the image, since it's been generated, appears.

I don't know much about JQuery at this point so I'm mostly lost.

The image is probably cached in your browser. You can trick it to think it's a different url and then it should load the updated version. .attr('src', 'IMAGEFILE?timestamp=' + (new Date() - 0))

# ? Aug 12, 2015 02:13

Ghost of Reagan Past: Oct 7, 2003; rock and roll fun

obstipator posted:

The image is probably cached in your browser. You can trick it to think it's a different url and then it should load the updated version. .attr('src', 'IMAGEFILE?timestamp=' + (new Date() - 0))

Cool, that did it, thanks!

# ? Aug 12, 2015 02:16

obstipator: Nov 8, 2009; by FactsAreUseless

Has anyone used wallabyjs? It looks useful, but they have a semi-subscription based license that seems expensive compared to other things that cost money, so I'm wondering if its worth throwing the cash at it. It probably is, but I'm just cautious since its foreign to me to have useful coding software not at least have a (non-trial) free version or a similar product alternative that is free.

# ? Aug 14, 2015 15:43

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

The license doesn't look like a subscription to me, just a purchase and free upgrades for a year, then discounted upgrades after that. You can keep using whatever version you purchase forever without paying more, AFAICT.

# ? Aug 14, 2015 16:30

IronDoge: Nov 6, 2008

obstipator posted:

Has anyone used wallabyjs? It looks useful, but they have a semi-subscription based license that seems expensive compared to other things that cost money, so I'm wondering if its worth throwing the cash at it. It probably is, but I'm just cautious since its foreign to me to have useful coding software not at least have a (non-trial) free version or a similar product alternative that is free.

There's a license section on their site which specifically says:

quote:

All of the above licenses permit the perpetual use of the latest version of wallaby.js at the time of purchase, and all new versions released within 12 months of license purchase. After the first 12 months, the license can be upgraded for 50% of the normal price.

# ? Aug 14, 2015 19:50

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

So what is the benefit of JSX? I realize that it allows you to write HTML style code straight from javascript but how is it really any different than writing straight HTML code strings and using .html(), .prepend() or .append() JQuery methods.

# ? Aug 17, 2015 16:50

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Knifegrab posted:

So what is the benefit of JSX? I realize that it allows you to write HTML style code straight from javascript but how is it really any different than writing straight HTML code strings and using .html(), .prepend() or .append() JQuery methods.

Everything is declarative and you can't make a mistake by manipulating the raw DOM.

# ? Aug 17, 2015 17:00

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

Suspicious Dish posted:

Everything is declarative and you can't make a mistake by manipulating the raw DOM.

Can you expand on this, I don't completely understand what you are saying.

# ? Aug 17, 2015 18:21

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

It also allows variable interpolation without opening up the risk of XSS.

# ? Aug 17, 2015 18:26

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Knifegrab posted:

So what is the benefit of JSX? I realize that it allows you to write HTML style code straight from javascript but how is it really any different than writing straight HTML code strings and using .html(), .prepend() or .append() JQuery methods.

You can have designer types who aren't terribly proficient in js write React components for you. It's much more "visual" in what the structure of nested components looks like. Many prefer the more terse syntax.

# ? Aug 17, 2015 18:45

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

And invalid HTML (unbalanced tags or quoting, f.e.) becomes a compile-time error rather than a runtime one.

# ? Aug 17, 2015 18:50

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Knifegrab posted:

Can you expand on this, I don't completely understand what you are saying.

Write a toy React app. It's something you'll only understand from experience.

# ? Aug 17, 2015 18:55

necrotic: Aug 2, 2005; I owe my brother big time for this!

Knifegrab posted:

Can you expand on this, I don't completely understand what you are saying.

JSX is "compiled" into raw-JS like so:

code:

<Butte flacid="cock">Stick it</Butte>

=>

React.createElement(Buttes, {"flacid": "cock"}, "Stick it")

It is very different from doing raw HTML with html or such stuff.

# ? Aug 17, 2015 21:03

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

necrotic posted:

JSX is "compiled" into raw-JS like so:
code:
<Butte flacid="cock">Stick it</Butte>

=>

React.createElement(Buttes, {"flacid": "cock"}, "Stick it")
It is very different from doing raw HTML with html or such stuff.

No I get that, but what I don't undertand is how writing:

code:

<butte flacid="cock">Stick it</Butte>

Is so much better than writing:

code:

$(#element).html("<butte flacid="cock">Stick it</Butte>");

I understand now the compiler time failure vs runtime failure, and that makes sense. But how does it prevent XSS attacks? How is the utilization of html() vulnerable to XSS attacks?

The term "variable interpolation" is one of those smart words that I am too dumb to understand. Is it similar to parameterizing a sql query to prevent injection?

# ? Aug 17, 2015 22:17

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Knifegrab posted:

No I get that, but what I don't undertand is how writing:
code:
<butte flacid="cock">Stick it</Butte>
Is so much better than writing:
code:
$(#element).html("<butte flacid="cock">Stick it</Butte>");
I understand now the compiler time failure vs runtime failure, and that makes sense. But how does it prevent XSS attacks? How is the utilization of html() vulnerable to XSS attacks?

The term "variable interpolation" is one of those smart words that I am too dumb to understand. Is it similar to parameterizing a sql query to prevent injection?

In your more verbose example above, you would actually have an error because of the quotes inside the string. That's related to how you get XSS attacks through variable interpolation/substitution.

If you had the thing to stick in a variable, you might say

code:

var thing = getThing();
$("#element").html("<butte flaccid='cock'>Stick " + thing + "</butte>");

which is OK, but what happens if thing itself contains a quote? That's the path to XSS. You can remember to escape every time you do that (but don't double-escape!), of course, but relying on programmers to remember things is generally a path to exciting security bugs.

In JSX, you would write:

code:

var thing = getThing();
return <Butte flaccid="cock">Stick {thing}</Butte>;

and the JSX processor makes sure that things are escaped properly.

# ? Aug 17, 2015 22:29

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

Subjunctive posted:

In your more verbose example above, you would actually have an error because of the quotes inside the string. That's related to how you get XSS attacks through variable interpolation/substitution.

If you had the thing to stick in a variable, you might say
code:
var thing = getThing();
$("#element").html("<butte flaccid='cock'>Stick " + thing + "</butte>");
which is OK, but what happens if thing itself contains a quote? That's the path to XSS. You can remember to escape every time you do that (but don't double-escape!), of course, but relying on programmers to remember things is generally a path to exciting security bugs.

In JSX, you would write:
code:
var thing = getThing();
return <Butte flaccid="cock">Stick {thing}</Butte>;
and the JSX processor makes sure that things are escaped properly.

Awesome, thanks Subjunctive, you continue to be a rad dude to me.

# ? Aug 17, 2015 23:48

Bhaal: Jul 13, 2001; I ain't going down alone; Dr. Infant, MD

Knifegrab posted:

No I get that, but what I don't undertand is how writing:

[jsx]

Is so much better than writing:

[js]

In addition to what others are saying, it's also :airquote:

better

because the former lets you read & construct in a medium that is much closer to the resulting artifact (ignoring all the spans thrown in). I use airquotes because readability arguments can turn into philosophical battles and "better" is kind of under-equipped as a form of comparison. That said I just recently wrapped up the 1.0 of a little self project using react and agree that it can be a very powerful tool and reading dev blogs didn't really make it all click for me. I'm averse to "Now you're thinking in ..." type slogans that just try to self promote their tech stack, but with React it sort of panned out that way for me where once I was comfortable enough with how they structure things it really seems quite sensible. Returning to backbone or whatever just feels like it's going to be clunky to me now. So I'm in the camp that feels it's better or at least a solid progressive step forward.

quote:

The term "variable interpolation" is one of those smart words that I am too dumb to understand. Is it similar to parameterizing a sql query to prevent injection?

Kind of, and it does come off as fancy language. Something like db.query("select * from users where id=?", user_id) would be a form of it. Interpolation ("between the poles") in this context just means that variables and everything else all fit inside of one string. There's no composition or glue or whatever else needed. "I've worked at $COMPANY since $HIRE_DATE." is just a single, atomic... thing, so therefore the variables have been interpolated into the thing. Versus eg. "I've worked at "+company [...] which is not interpolated. The interpolated string still needs to be cut up and other bits will get substituted around, yeah, but all of that is abstracted and contained so you don't have to do all of it yourself every time, which closes out a ton of opportunities for typos and bugs and so on eating up developer time. That's the central advantage of it, in a nutshell.

Bhaal fucked around with this message at 01:45 on Aug 18, 2015

# ? Aug 18, 2015 01:28

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

Thanks for all the info Bhaal, it really helps me a lot!

# ? Aug 18, 2015 02:36

stoops: Jun 11, 2001

(I'm putting this in there since Canvas uses javascripting)

I have an image that will need to have lines on it, horizontal and vertical, like a grid.

I'm not drawing the lines using my mouse. I have a form asking the user for x amount of vertical lines and x amount of horizontal lines. On submission, the lines appear on the image.

After the lines are on the image, I need to be able to move the lines around on their x or y axis, but not overlap each other.

Currently, I'm using Canvas to draw the lines, but I'm not sure how to make them draggable, or if Canvas is the right way to go.

Is there something else I should be using for this? SVG?

Any info is appreciated.

# ? Aug 20, 2015 17:54

Tres Burritos: Sep 3, 2009

stoops posted:

(I'm putting this in there since Canvas uses javascripting)

I have an image that will need to have lines on it, horizontal and vertical, like a grid.

I'm not drawing the lines using my mouse. I have a form asking the user for x amount of vertical lines and x amount of horizontal lines. On submission, the lines appear on the image.

After the lines are on the image, I need to be able to move the lines around on their x or y axis, but not overlap each other.

Currently, I'm using Canvas to draw the lines, but I'm not sure how to make them draggable, or if Canvas is the right way to go.

Is there something else I should be using for this? SVG?

Any info is appreciated.

Yeah, making them draggable isn't going to work without quite a bit of extra code with canvas. SVG is definitely the way to go, you can use native event listeners and stuff. If you need the image to be saved to the users computer, then you should draw the image to canvas with lines as only the last step.

# ? Aug 20, 2015 18:14

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

stoops posted:

lines problem

If you've got some work done already, post a fiddle so that people can help to extend (or advise that you toss) the current state of affairs.

# ? Aug 20, 2015 18:16

stoops: Jun 11, 2001

Tres Burritos posted:

Yeah, making them draggable isn't going to work without quite a bit of extra code with canvas. SVG is definitely the way to go, you can use native event listeners and stuff. If you need the image to be saved to the users computer, then you should draw the image to canvas with lines as only the last step.

Thanks, I ended up using SVG and an SVG draggable script.

# ? Aug 20, 2015 23:48

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

So I am trying to utilize JSX in my latest project. I understand that is a pre-runtime compiling thing, in that I have ot transform my JSX to javascript, but I cannot figure out an easy way to do that. There are somethings online about using npm to install jsx and then to output it to JS files, but I mean that doesn't seem like the best solution for doing the front end development which doesn't use node. Is this how everyone does it, how do people out there manage their JSX compilation, it seems like another layer of PITA between writing and test.

# ? Aug 22, 2015 00:29

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

Knifegrab posted:

So I am trying to utilize JSX in my latest project. I understand that is a pre-runtime compiling thing, in that I have ot transform my JSX to javascript, but I cannot figure out an easy way to do that. There are somethings online about using npm to install jsx and then to output it to JS files, but I mean that doesn't seem like the best solution for doing the front end development which doesn't use node. Is this how everyone does it, how do people out there manage their JSX compilation, it seems like another layer of PITA between writing and test.

The ol' react.js site lists these two methods:
- link the JSX transformer script on your page, which will transpile the JSX on runtime (don't do this in production, this is stupid, use the below items)
- install the react-tools package from npm and use that to transpile the JSX on build, this is good and portable and every other way of doing this (aside from the script above) uses this in some way.

Here are some plugins I googled for the major build systems:
- 'gulp-react' for gulp
- 'grunt-jsx' for grunt
- 'babel-loader' for webpack, which actually uses Babel.js which supports far more transpiling options
- 'broccoli-react' for broccoli

You can also replace any of the above with their Babel equivalent since Babel supports JSX. Also if you use TypeScript then TypeScript's compiler supports it now too I think.

If you really really don't want to use a real build system then just add a 'postinstall' script to package.json with a command to build the jsx using react-tools (something like 'jsx src/ build/') and be sure to run the postinstall script when you want to build your site.

If you are only somewhat hesitant about using a real build system then just go ahead and use one, they're not that difficult to get started with and let you do a lot more fun stuff with it than just JSX. If you're just hesitant about having to run a build script every time you want to test something out locally then all of these build systems come with watch/reload scripts that will do it for you. If you're just hesitant about having to run a build script before deploy then you're kind of weird, just bite the bullet and use one.

# ? Aug 22, 2015 00:52

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

piratepilates posted:

The ol' react.js site lists these two methods:
- link the JSX transformer script on your page, which will transpile the JSX on runtime (don't do this in production, this is stupid, use the below items)
- install the react-tools package from npm and use that to transpile the JSX on build, this is good and portable and every other way of doing this (aside from the script above) uses this in some way.

Here are some plugins I googled for the major build systems:
- 'gulp-react' for gulp
- 'grunt-jsx' for grunt
- 'babel-loader' for webpack, which actually uses Babel.js which supports far more transpiling options
- 'broccoli-react' for broccoli

You can also replace any of the above with their Babel equivalent since Babel supports JSX. Also if you use TypeScript then TypeScript's compiler supports it now too I think.

If you really really don't want to use a real build system then just add a 'postinstall' script to package.json with a command to build the jsx using react-tools (something like 'jsx src/ build/') and be sure to run the postinstall script when you want to build your site.

If you are only somewhat hesitant about using a real build system then just go ahead and use one, they're not that difficult to get started with and let you do a lot more fun stuff with it than just JSX. If you're just hesitant about having to run a build script every time you want to test something out locally then all of these build systems come with watch/reload scripts that will do it for you. If you're just hesitant about having to run a build script before deploy then you're kind of weird, just bite the bullet and use one.

Awesome, grabbing the transformer worked like magic, I don't know how I missed that on their site. Thanks for all the extra info too.

I've got another "knifegrab is a giant moron" question. What the gently caress is a virtualized DOM and how is it different from a normal DOM?

# ? Aug 22, 2015 01:43

Depressing Box: Jun 27, 2010; Half-price sideshow.

Knifegrab posted:

I've got another "knifegrab is a giant moron" question. What the gently caress is a virtualized DOM and how is it different from a normal DOM?

The short version is that working with the real DOM is slow, so React makes its changes to a virtual DOM that only exists in javascript, then compares it to the real DOM to decide what actually needs to be updated.

# ? Aug 22, 2015 01:50

Kekekela: Oct 28, 2004

Knifegrab posted:

What the gently caress is a virtualized DOM and how is it different from a normal DOM?

Its like a copy of the DOM that react maintains internally. When you are rendering components etc the operations are taking place on the virtualized DOM, which can then be compared to the real DOM so that only the necessary changes need to be applied.

Also as far as the other stuff, I'm liking babel since it lets me get used to new ES2015 module syntax etc. I've been using this boilerplate for my current meanderings: https://github.com/vasanthk/react-es6-webpack-boilerplate

# ? Aug 22, 2015 01:54

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

Knifegrab posted:

Awesome, grabbing the transformer worked like magic, I don't know how I missed that on their site. Thanks for all the extra info too.

I've got another "knifegrab is a giant moron" question. What the gently caress is a virtualized DOM and how is it different from a normal DOM?

The theory is that making constant changes to the actual DOM is expensive -- every time you make a change the browser's rendering engine has to do a bunch of stuff to make the actual change, then reflows, then re-rendering.

React.js is architected in a way that every time the 'source of truth' (prop or state) for a component (element? class? I forget what they call it, the thing that gets turned in to an HTML element) is changed, the entire tree of components deriving from that source is just re-rendered completely.

Re-rendering the entire tree would (probably, and truthfully) be quite expensive if stuff doesn't actually change much, while at the same time re-rendering the entire tree to javascript first would be quite fast (it seriously would, render functions if you're not doing it very wrong are doing very little work, at most a bit of iterating over a small sized list). So the React team decided to have React components render to a javascript object first, and then React will compare the javascript object to the actual DOM and see what changed, then it can deem if it's worth making changes to the actual DOM. If the DOM doesn't need to be changed then no costly modifications, reflows, re-renders, etc. If the DOM does need to be changed, then you would have changed it otherwise so it doesn't matter.

Take the case of a Twitter feed for example. You have a bunch of tweets in a list, your React component iterates through the list and outputs an <li> element for each tweet. If someone makes a new tweet that ends up in your feed then React will run the render function again and go through the list, outputting the <li> elements again for each tweet. Now you should be saying to yourself at this point "wait what, that's dumb, only one tweet changed, why are we changing all of them?" and you'd be right except that if you're doing this process in javascript for reasonably sized (less than millions of objects) collections, then it doesn't take long at all to run the render function and you get all the nice immutability from this. After the render function spits out the new <li> elements React just has to check if anything really changed from what has been rendered, and since it will notice that only one <li> element changed, it will only update the one element on the real DOM.

edit: Here's a virtual dom library: https://github.com/Matt-Esch/virtual-dom

I don't think that's the one React uses (I bet they just use something that was made for React only) but it gives a good rundown and does almost exactly the same thing.

piratepilates fucked around with this message at 02:03 on Aug 22, 2015

# ? Aug 22, 2015 02:00

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

The normal DOM is directly connected to the document: when you make a call into it (appendChild or setAttribute, say), the browser's representation of the document is updated, and appropriate graphical changes happen right away. The document underlying the DOM is a relatively heavyweight thing for a number of reasons, and so modifications to it can be comparatively slow.

A virtual DOM is an inexpensive "fake" representation of the DOM, such that changing it (or creating one) is much much cheaper. React and other such toolkits have you manipulate the virtual DOM however you want -- in react's case constructing fragments from scratch all the time -- and then compute the cheapest DOM operations that will make the real DOM match what you've done to the virtual one.

You can imagine a room with a bunch of furniture in it. You want the furniture to be in some different configurations -- say the couch gets pulled out and the coffee table pushed aside when there are guests. You can do a few things:

keep track of where everything is so you know what changes to make to get to what you want. Maybe the coffee table gets pushed aside already for dancing before bed, so don't do it twice!
just take everything out of the room at dancing time, and bedtime, and when the guests leave, and then put it back the way it should be at the moment. You don't have to remember what's already where, but you'll be a sweaty mess.
make a map of the room with post-it notes for the furniture. Then you can take all the pieces off, and put them in the right places from scratch, without breaking your back or worrying about what order to move things. (Your roommate gets to decide whether the lamp is on, so you just have him put the right sticker down and don't worry about it yourself.) Then you hand your new map to React Room Organizer Bot and it moves the minimal set of stuff to get the room just the way you want it.

There are some over-simplifications there (DOM updates don't paint immediately, the change set that React computes isn't always minimal), but that's the basic idea.

e;fb but I typed that on my phone so gently caress all of you I'm leaving it.

# ? Aug 22, 2015 02:06

Mr_Angry: May 15, 2003; A severe disappointment; College Slice

I'm an experienced C/C++ programmer who has also done C# projects and now finds himself taking on a rather large JavaScript effort. I've not programmed in Java in years and I'd definitely like a good learning resource as I start going through all this code and realistically taking on another language (I've not been hands-on in a while so this is a good thing). Is the best resource the O'Reilly Learning JavaScript, 2nd Edition (the 3rd edition is not out yet it seems) book or is there another resource people would recommend? Thanks.

# ? Aug 24, 2015 10:59

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

^^^ You don't know JS was recommended to me and I think quite highly of it. Plus its free on github, or you could always buy some physical copies off amazon.

Subjunctive posted:

The normal DOM is directly connected to the document: when you make a call into it (appendChild or setAttribute, say), the browser's representation of the document is updated, and appropriate graphical changes happen right away. The document underlying the DOM is a relatively heavyweight thing for a number of reasons, and so modifications to it can be comparatively slow.

A virtual DOM is an inexpensive "fake" representation of the DOM, such that changing it (or creating one) is much much cheaper. React and other such toolkits have you manipulate the virtual DOM however you want -- in react's case constructing fragments from scratch all the time -- and then compute the cheapest DOM operations that will make the real DOM match what you've done to the virtual one.

You can imagine a room with a bunch of furniture in it. You want the furniture to be in some different configurations -- say the couch gets pulled out and the coffee table pushed aside when there are guests. You can do a few things:

keep track of where everything is so you know what changes to make to get to what you want. Maybe the coffee table gets pushed aside already for dancing before bed, so don't do it twice!

just take everything out of the room at dancing time, and bedtime, and when the guests leave, and then put it back the way it should be at the moment. You don't have to remember what's already where, but you'll be a sweaty mess.

make a map of the room with post-it notes for the furniture. Then you can take all the pieces off, and put them in the right places from scratch, without breaking your back or worrying about what order to move things. (Your roommate gets to decide whether the lamp is on, so you just have him put the right sticker down and don't worry about it yourself.) Then you hand your new map to React Room Organizer Bot and it moves the minimal set of stuff to get the room just the way you want it.

There are some over-simplifications there (DOM updates don't paint immediately, the change set that React computes isn't always minimal), but that's the basic idea.

e;fb but I typed that on my phone so gently caress all of you I'm leaving it.

This and everyone else's explanations are fantastic, thank you guys so much. Is a virtualized DOM a standard thing? Or is it something unique to each framework that might use it? Or what I am saying is this: Is the virtualized DOM some kind of common browser interface, or is it merely React's own virtualization implementation?

# ? Aug 24, 2015 15:19

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Knifegrab posted:

^^^ You don't know JS was recommended to me and I think quite highly of it. Plus its free on github, or you could always buy some physical copies off amazon.

This and everyone else's explanations are fantastic, thank you guys so much. Is a virtualized DOM a standard thing? Or is it something unique to each framework that might use it? Or what I am saying is this: Is the virtualized DOM some kind of common browser interface, or is it merely React's own virtualization implementation?

Virtual DOM is a "new to the mainstream" thing with many different implementations. I think React's implementation was the first "big" thing that made people start talking about it a lot.

# ? Aug 24, 2015 15:39

pepito sanchez: Apr 3, 2004; I'm not mexican

i wasn't very familiar with what a virtual DOM was either so i looked around. this sums it up pretty well. they are talking about React in this case:

quote:

One of the most important concepts of this project is the virtual DOM. You can think of it as a set of elements that you can modify with your data and which, in the end, will modify the page�s real DOM. The virtual DOM is used for efficient re-rendering of the DOM by using a diff algorithm that only re-renders the components changed. This in turn enables the library to be ultra fast.

Another great feature is that it can also render on the server using Node.js. Therefore, you can use the same knowledge you�ve gained both on the client and on the server. This has major performance and SEO benefits. Many developers are using React.js to render a first, static version of the page on the server, which is faster than doing so on the client and is also SEO-friendly. Then they enable fast user interactions and UI updates by using React.js on the client side.

also i'm not too familiar with React so i have to ask: since React isn't really a framework, is Relay Facebook's answer for the M and C in MVC?

edit: one more for the React.js people: has mixing the view with logic ever been a real issue with you? i like SOC, and it's just absolutely missing in React.

pepito sanchez fucked around with this message at 16:03 on Aug 24, 2015

# ? Aug 24, 2015 15:51

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

pepito sanchez posted:

also i'm not too familiar with React so i have to ask: since React isn't really a framework, is Relay Facebook's answer for the M and C in MVC?

I'd say no. This is my "I read about things on the internet" opinion, but Relay is not a model, and definitely not a controller. Relay is a way of composing data requirements if you are using GraphQL. Instead of adding a new React child component that shows a user's favorite ice cream and then saying "Okay, I need to go up the parent chain to see where I should add fav_ice_cream as a prop or maybe I need to tweak the back-end so the ice cream is added because it's not now... :ohdear:

" With Relay, the component that displays the favorite ice cream has a thing that says "I need to know about a user's favorite ice cream" and when the GraphQL call for data fetching happens, that requirement (along with all the other component's requirements) are consolidated and turned into a GraphQL query, which returns exactly the data needed in the shape it's needed in.

At least, that's what I've understood from watching some talks and reading some articles.

# ? Aug 24, 2015 16:05

WORLDS BEST BABY: Aug 26, 2006

Lumpy posted:

I'd say no. This is my "I read about things on the internet" opinion, but Relay is not a model, and definitely not a controller. Relay is a way of composing data requirements if you are using GraphQL. Instead of adding a new React child component that shows a user's favorite ice cream and then saying "Okay, I need to go up the parent chain to see where I should add fav_ice_cream as a prop or maybe I need to tweak the back-end so the ice cream is added because it's not now... " With Relay, the component that displays the favorite ice cream has a thing that says "I need to know about a user's favorite ice cream" and when the GraphQL call for data fetching happens, that requirement (along with all the other component's requirements) are consolidated and turned into a GraphQL query, which returns exactly the data needed in the shape it's needed in.

At least, that's what I've understood from watching some talks and reading some articles.

I'd say GraphQL is the model, whereas Relay definitely has some controller-y aspects to it: it can also change data in your model via typed 'mutations' in addition to its data querying.

# ? Aug 24, 2015 16:27

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 17:26

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

MVC is kind of vague at this point since every framework has their own take of it labeled the same even if they do it very differently.

Edit: I forgot to mention, Facebook deliberately doesn't describe any of this as MVC, and that's probably not that bad of an idea.

React handles turning data in to views, and user interaction from views in to actions. This is probably closest to the V.

Flux handles turning actions in to more actions. This is probably the C, you handle actions by defining how the model and views will change by those actions.

Relay handles network requests for data. It handles turning actions in to data, and current data in to network requests for more days. This is part of the M but I don't think it defines how the data is stored or handled on the front end, only how to communicate with the backend.

From what I gather about the whole picture (and I'm sure Subjunctive has a lot to say about all of it), the hands on implementation would be to use React for views, communicating with Flux to drive all of the other components and state, Relay to talk to your backends, Immutable.js for data structures and nice immutability, and Flow for type checking all of it.

piratepilates fucked around with this message at 17:26 on Aug 24, 2015

# ? Aug 24, 2015 17:18

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »