Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

spacebard: Jan 1, 2007; Football~

I'm finally getting to play with react and redux. I'm seeing a lot of the following (in the Todo List Example for instance):

code:

const TodoList = ({ todos, onTodoClick }) => (
  <ul>
    {todos.map(todo =>
      <Todo
        key={todo.id}
        {...todo}
        onClick={() => onTodoClick(todo.id)}
      />
    )}
  </ul>
)

Is this good practice these days? I've spent the last X years trying to avoid inline JavaScript on elements.

Should doing something like documented on DOM Event Listeners be better? This has an example of binding an event to the window, but that seems bad too. Does the onClick binding on a component transpile into something else?

Can I bind to the Component or element inside componentDidMount instead of window?

code:

  componentDidMount: function() {
    window.addEventListener('click', this.handleClick);
  },
  handleClick: function(e) {
    e.preventDefault();
    // Do stuff
  }

# ? Jul 13, 2016 21:31

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 23:32

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

Short answer, browser DOM !== React DOM, so inline JavaScript is OK. You're not actually putting inline scripts into the output HTML, it's being used by React internally, and the events you're interacting with are actually SyntheticEvent objects.

Ideally, you want your React components to avoid directly interacting with the browser as much as possible, as this makes them easier to maintain, test, and/or run isomorphically.

# ? Jul 13, 2016 21:49

bartkusa: Sep 25, 2005; Air, Fire, Earth, Hope

spacebard posted:

I've spent the last X years trying to avoid inline JavaScript on elements.

Should doing something like documented on DOM Event Listeners be better?

No. It's fine. Do what React says.

It's not really creating an onclick-handler as a string on the DOM element. The React renderer is basically creating and attaching a DOM event listener under the covers. The onClick that you're writing is just declaring that React should do that for you.

(Actually, that's a lie, too. React has its own goofy synthetic event system. Probably to work around some performance issue I'm not even aware of. It works great most of the time, but I've run into 1 or 2 edge cases where I had to revert to creating DOM event listeners in componentDidMount.)

e: f;b

# ? Jul 13, 2016 21:54

spacebard: Jan 1, 2007; Football~

Depressing Box posted:

Short answer, browser DOM !== React DOM, so inline JavaScript is OK. You're not actually putting inline scripts into the output HTML, it's being used by React internally, and the events you're interacting with are actually SyntheticEvent objects.

Ideally, you want your React components to avoid directly interacting with the browser as much as possible, as this makes them easier to maintain, test, and/or run isomorphically.

Ah, Okay. Thanks. That makes sense and I can live with that. I read about SyntheticEvent, but it didn't really help clarify things yet. :downs:

My basic plan for this app I'm working on is to have some links set off actions with a reducer changing some global state on my redux store.

Edit: It also makes much more sense to have the events there as to not pollute the browser DOM as much.

spacebard fucked around with this message at 22:32 on Jul 13, 2016

# ? Jul 13, 2016 22:29

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

The problems with <div onclick="buttzone()"> was the lack of proper namespacing / scoping, since everything needed to be global. React fixes that by allowing you to bind to functions by reference rather than evaluated strings. I don't know why people switched to elem.addEventListener('click', buttzone); instead of doing elem.onclick = buttzone; when the latter is much simpler and less confusing with multiple handlers and such.

# ? Jul 13, 2016 23:06

Ethereal: Mar 8, 2003

spacebard posted:

I'm finally getting to play with react and redux. I'm seeing a lot of the following (in the Todo List Example for instance):
code:
const TodoList = ({ todos, onTodoClick }) => (
  <ul>
    {todos.map(todo =>
      <Todo
        key={todo.id}
        {...todo}
        onClick={() => onTodoClick(todo.id)}
      />
    )}
  </ul>
)
Is this good practice these days? I've spent the last X years trying to avoid inline JavaScript on elements.

Should doing something like documented on DOM Event Listeners be better? This has an example of binding an event to the window, but that seems bad too. Does the onClick binding on a component transpile into something else?

Can I bind to the Component or element inside componentDidMount instead of window?
code:
  componentDidMount: function() {
    window.addEventListener('click', this.handleClick);
  },
  handleClick: function(e) {
    e.preventDefault();
    // Do stuff
  }

You don't want to have inline click handlers ever on your components. What happens is that on each re-render you will generate a new function which causes downstream children to re-render. It's also a bit thrashy generating new functions like this all the time.

In an ideal world you would split off the individual child component and have a handler that you can call directly.

code:

class TodoItem extends React.Component {
  onClickHandler = (e) => {
    e.preventDefault();
    this.props.onTodoClick(this.props.todoId);
  }

  render() {
     <Todo onClick={this.onClickHandler}.../>
  }
}

const TodoList = ({ todos, onTodoClick }) => (
  <ul>
    {todos.map(todo =>
      <TodoItem
        key={todo.id}
        {...todo}
        onTodoClick={onTodoClick}
        todoId={todo.id}
      />
    )}
  </ul>
)

# ? Jul 14, 2016 05:02

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Suspicious Dish posted:

The problems with <div onclick="buttzone()"> was the lack of proper namespacing / scoping, since everything needed to be global. React fixes that by allowing you to bind to functions by reference rather than evaluated strings. I don't know why people switched to elem.addEventListener('click', buttzone); instead of doing elem.onclick = buttzone; when the latter is much simpler and less confusing with multiple handlers and such.

Because unless you're very disciplined in controlling event attaching that'll cause things to Mysteriously Break when someone stomps on the handler that someone else assigns. You also have to have total control of the content of the page with no third party anything that might want to attach an event to anything, which is usually an edge case for a working professional IME.

It's too bad the DOM doesn't support += and -= because that'd at least be much cleaner to read.

# ? Jul 14, 2016 14:47

Pollyanna: Mar 5, 2005; Milk's on them.

What's the point at which you should start using a framework? Our big ol' dynamic HTML table/Excel spreadsheet replacement/inline form editing Frankenstein has an issue with hiding/resetting forms via a cancel button and after fiddling around with jQuery spaghetti and completely disorganized, inline source code, I'm frustrated enough to want to convert the whole thing to a React component instead of Rails form helpers and wash my hands of the whole thing. Front-end poo poo has been a recurring issue for us and absolutely none of it makes sense. :gonk:

The lack of a framework is making things just totally stupid.

# ? Jul 14, 2016 16:04

Opulent Ceremony: Feb 22, 2012

Pollyanna posted:

What's the point at which you should start using a framework? Our big ol' dynamic HTML table/Excel spreadsheet replacement/inline form editing Frankenstein has an issue with hiding/resetting forms via a cancel button and after fiddling around with jQuery spaghetti and completely disorganized, inline source code, I'm frustrated enough to want to convert the whole thing to a React component instead of Rails form helpers and wash my hands of the whole thing. Front-end poo poo has been a recurring issue for us and absolutely none of it makes sense. The lack of a framework is making things just totally stupid.

I maintain several pages like this at work. How large and complex is your page currently? If it isn't terrible and if your team already has a preferred framework being used elsewhere in the application, it could be a great idea to convert it. The pages I mentioned have no hope of conversion: they are enormous, very complex, have no tests, and maintain such a tremendous list of undocumented specific functionality that even if I wanted to rewrite the whole thing, I wouldn't even be able to tell if it did everything it was supposed to and would be bombarded constantly with critical hotfix requests as a result of the heavy client use they see. Don't let it become like the pages I inherited.

# ? Jul 14, 2016 17:39

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

Pollyanna posted:

What's the point at which you should start using a framework? Our big ol' dynamic HTML table/Excel spreadsheet replacement/inline form editing Frankenstein has an issue with hiding/resetting forms via a cancel button and after fiddling around with jQuery spaghetti and completely disorganized, inline source code, I'm frustrated enough to want to convert the whole thing to a React component instead of Rails form helpers and wash my hands of the whole thing. Front-end poo poo has been a recurring issue for us and absolutely none of it makes sense. The lack of a framework is making things just totally stupid.

try refactoring it before rewriting it to the latest hotness

# ? Jul 14, 2016 18:23

Pollyanna: Mar 5, 2005; Milk's on them.

Suspicious Dish posted:

try refactoring it before rewriting it to the latest hotness

This is how I'm refactoring it. It's a use case that clearly doesn't map well to the technology used to make it (Rails forms), and faking SPA-like behavior by using XHR requests to load up HTML and recording state in the markup is only making this harder to debug and understand, and it's slowing us down. The app needs to move on from throwaway jQuery callbacks and slapdash element styling if we want to go further with it, or it's just going to get worse.

Opulent Ceremony posted:

I maintain several pages like this at work. How large and complex is your page currently? If it isn't terrible and if your team already has a preferred framework being used elsewhere in the application, it could be a great idea to convert it. The pages I mentioned have no hope of conversion: they are enormous, very complex, have no tests, and maintain such a tremendous list of undocumented specific functionality that even if I wanted to rewrite the whole thing, I wouldn't even be able to tell if it did everything it was supposed to and would be bombarded constantly with critical hotfix requests as a result of the heavy client use they see. Don't let it become like the pages I inherited.

It's not particularly large, but it's disorganized enough that the complexity is way higher than it should be. We have no real framework in our application aside from some jQuery scattered about. There's a team writing regression tests (Capybara stuff) right now, so maybe once those are finished I'll bring up the idea of fixing our front-end to not be insane.

# ? Jul 15, 2016 02:18

HaB: Jan 5, 2001; What are the odds?

Pollyanna posted:

What's the point at which you should start using a framework? Our big ol' dynamic HTML table/Excel spreadsheet replacement/inline form editing Frankenstein has an issue with hiding/resetting forms via a cancel button and after fiddling around with jQuery spaghetti and completely disorganized, inline source code, I'm frustrated enough to want to convert the whole thing to a React component instead of Rails form helpers and wash my hands of the whole thing. Front-end poo poo has been a recurring issue for us and absolutely none of it makes sense. The lack of a framework is making things just totally stupid.

I'd say the time to start using a framework is pretty much: whenever you decide it's worth it, and from your posts about this - it sounds like you are already to that point. If I get assigned a jQuery project I will usually propose converting it immediately, because ANY modern framework is so far above jQuery that it's pretty much automatically worth it, to me.

Convert it. One less jQuery project in the world is a boon.

# ? Jul 15, 2016 12:34

Huzanko: Aug 4, 2015; by FactsAreUseless

Xik posted:

May I ask why?

It's a genuine question, I'm about to spend a bunch of effort learning (and then using) angular. Workplace has decided to use angular as the front-end for a bunch of app rewrites that will be happening over the next couple years.

Angular 1 is great if you conform to: https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md

However, most example and tutorial code, and the code that has been written based on those examples, do not, hence a lot of people hate Angular 1 since, for some reason, most example code is poo poo garbage that should never have been written or suggested.

# ? Jul 15, 2016 16:22

ModeSix: Mar 14, 2009

Noam Chomsky posted:

Angular 1 is great if you conform to: https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md

However, most example and tutorial code, and the code that has been written based on those examples, do not, hence a lot of people hate Angular 1 since, for some reason, most example code is poo poo garbage that should never have been written or suggested.

Thanks for this, it's pretty fantastic and I learned a few things just from skimming it.

# ? Jul 15, 2016 17:28

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Noam Chomsky posted:

Angular 1 is great if you conform to: https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md

However, most example and tutorial code, and the code that has been written based on those examples, do not, hence a lot of people hate Angular 1 since, for some reason, most example code is poo poo garbage that should never have been written or suggested.

If you are using Angular 1.5, I would also take a look at this https://github.com/toddmotto/angular-styleguide

It does a pretty good rundown on how to write your app as a component tree, which is almost spot on how Angular 2 works.

# ? Jul 15, 2016 20:23

ModeSix: Mar 14, 2009

Skandranon posted:

If you are using Angular 1.5, I would also take a look at this https://github.com/toddmotto/angular-styleguide

It does a pretty good rundown on how to write your app as a component tree, which is almost spot on how Angular 2 works.

This is also fantastic.

edit: :downs:

ModeSix fucked around with this message at 22:13 on Jul 16, 2016

# ? Jul 16, 2016 22:09

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Just saw this, thought it might be interesting for the thread.

http://react-etc.net/entry/your-license-to-use-react-js-can-be-revoked-if-you-compete-with-facebook

# ? Jul 17, 2016 17:42

wide stance: Jan 28, 2011; If there's more than one way to do a job, and one of those ways will result in disaster, then he will do it that way.

Skandranon posted:

Just saw this, thought it might be interesting for the thread.

http://react-etc.net/entry/your-license-to-use-react-js-can-be-revoked-if-you-compete-with-facebook

gently caress.

e: Probably ok

wide stance fucked around with this message at 18:46 on Jul 17, 2016

# ? Jul 17, 2016 18:42

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

Skandranon posted:

Just saw this, thought it might be interesting for the thread.

http://react-etc.net/entry/your-license-to-use-react-js-can-be-revoked-if-you-compete-with-facebook

Didn't we already have the broughaha over this a few months ago?

# ? Jul 17, 2016 19:18

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Lumpy posted:

Didn't we already have the broughaha over this a few months ago?

Yeah.

AFAICT, it basically works out like this (IANAL):

If you're using React, and then sue Facebook, the patent rider is revoked...but then that just means you're back in the patent grant state you are with any BSD-licensed software you're using.

BUT, its all just kind of noise because how the BSD license works with this patent grant or really patent grants in general is not very tested with any precendent or anything.

IMO, it's basically meaningless unless you're Google or Microsoft or something.

# ? Jul 17, 2016 19:48

abraham linksys: Sep 6, 2010

fwiw there was an earlier version of the patent grant with way less clear language, this version apparently had sign-offs from a couple concerned larger companies (including Google)

# ? Jul 17, 2016 19:49

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

There's an argument that the BSD license has an implied patent grant (as otherwise it doesn't actually grant you any of the rights it claims to), and that an explicit license grant would replace the implied one, rather than adding to it. No part of this argument has in any way been tested in court, though.

The older wording of the patent grant was really lovely and far more broad than it was supposed to be, but the new wording is basically the same as Apache 2.0 and no one has a problem with that.

# ? Jul 18, 2016 01:33

Stoph: Mar 19, 2006; Give a hug - save a life.

Then why don't they loving use Apache 2.0. It's a clusterfuck to be honest and a shame because they have community mindshare.

# ? Jul 18, 2016 23:59

Huzanko: Aug 4, 2015; by FactsAreUseless

http://news.dartlang.org/2016/07/angulardart-is-going-all-dart.html

quote:

Until now, the multiple language flavors of Angular 2 were written as TypeScript source, and then automatically compiled to both JavaScript and Dart. We're happy to announce that we�re splitting the Angular 2 codebase into two flavors � a Dart version and a TypeScript/JavaScript version � and creating a dedicated AngularDart team.

Just LOL.

Nice release candidate there. gently caress Angular 2. Makes me sad.

# ? Jul 22, 2016 16:27

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Noam Chomsky posted:

http://news.dartlang.org/2016/07/angulardart-is-going-all-dart.html

Just LOL.

Nice release candidate there. gently caress Angular 2. Makes me sad.

Can't say I've been too happy with how Angular 2 is shaping up either. Aurelia is looking to be more and more what I really wanted Angular 2 to be...

# ? Jul 22, 2016 16:40

Huzanko: Aug 4, 2015; by FactsAreUseless

Skandranon posted:

Can't say I've been too happy with how Angular 2 is shaping up either. Aurelia is looking to be more and more what I really wanted Angular 2 to be...

Yeah I am probably just jumping ship.

I plan to check out Aurelia or delve more deeply into React, which I haven't warmed up to despite trying. Or, I'll just use Angular 1.5 forever.

The Angular 2 team seems like a bunch of fuckups with ADD - continually fascinated with new shiny things, obsessed with technological purity, and benchmarks no one really cares about - and never considering the people who actually need and want to use the product/platform/whatever. So, pretty representative of the JS community.

I'm really loving disgusted.

# ? Jul 22, 2016 16:43

Spraynard Kruger: May 8, 2007

React just rolled out a configuration-less app creator: https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html

Spins up a Webpack/Babel/ESLint setup for you, no configuration files mixed in with your code or mountains of dependencies in your package.json necessary. Very cool stuff.

# ? Jul 22, 2016 18:32

aBagorn: Aug 26, 2004

Spraynard Kruger posted:

React just rolled out a configuration-less app creator: https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html

Spins up a Webpack/Babel/ESLint setup for you, no configuration files mixed in with your code or mountains of dependencies in your package.json necessary. Very cool stuff.

We were just talking about it on our team. It's really nice and clean. I'm very glad fb is putting these things out there

# ? Jul 22, 2016 18:36

Huzanko: Aug 4, 2015; by FactsAreUseless

Spraynard Kruger posted:

React just rolled out a configuration-less app creator: https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html

Spins up a Webpack/Babel/ESLint setup for you, no configuration files mixed in with your code or mountains of dependencies in your package.json necessary. Very cool stuff.

Man, that's just what I've been needing. Thanks!

# ? Jul 22, 2016 21:04

Huzanko: Aug 4, 2015; by FactsAreUseless

Is there any way to use WebPack without a Node server? Like use require and all the module stuff?

# ? Jul 22, 2016 21:35

Pollyanna: Mar 5, 2005; Milk's on them.

Spraynard Kruger posted:

React just rolled out a configuration-less app creator: https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html

Spins up a Webpack/Babel/ESLint setup for you, no configuration files mixed in with your code or mountains of dependencies in your package.json necessary. Very cool stuff.

Also important to note that there's an "eject" function that pushes all the internal configuration into your project repo and detaches you completely from the conventions. Makes going rogue a lot easier. I'm totally using this next time I do a React thing :3:

# ? Jul 22, 2016 22:00

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

Noam Chomsky posted:

Is there any way to use WebPack without a Node server? Like use require and all the module stuff?

webpack-dev-server is the only part that uses a Node server, and it's just for local development. The compiled output (npm run build in Create React App) is a bunch of regular JS/HTML/CSS/etc. that will run directly in the browser.

Depressing Box fucked around with this message at 22:28 on Jul 22, 2016

# ? Jul 22, 2016 22:21

Huzanko: Aug 4, 2015; by FactsAreUseless

Depressing Box posted:

webpack-dev-server is the only part that uses a Node server, and it's just for local development. The compiled output (npm run build in Create React App) is a bunch of regular JS/HTML/CSS/etc. that will run directly in the browser.

Cool. Thanks!

# ? Jul 22, 2016 22:37

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

What stage Babel transpilation does it do?

The problem with removing configuration is that...there are things people commonly want to configure!

# ? Jul 23, 2016 03:11

Pollyanna: Mar 5, 2005; Milk's on them.

Thermopyle posted:

What stage Babel transpilation does it do?

The problem with removing configuration is that...there are things people commonly want to configure!

Yes, and there's an option to bail and just shunt the default config into your project, which you can then customize.

# ? Jul 23, 2016 13:47

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Pollyanna posted:

Yes

"Yes" what?

# ? Jul 23, 2016 15:04

Pollyanna: Mar 5, 2005; Milk's on them.

Thermopyle posted:

"Yes" what?

Just kind of how I started the sentence.

# ? Jul 23, 2016 15:33

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I see. It looks like the answer to my question if you misread my question, so I was checking...

# ? Jul 23, 2016 16:57

Pollyanna: Mar 5, 2005; Milk's on them.

Ohhh, I see. That was a response to your second sentence, it should be customizable once you eject.

# ? Jul 23, 2016 17:02

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 23:32

ModeSix: Mar 14, 2009

I think it's similar to starting a sentence with "well" . I get it.

Sideshow commentary.

# ? Jul 23, 2016 17:44

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »