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

«‹›234 »

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Deffon posted:

I'm not sure what you're getting at with this? Those API:s are hard to work with, which is why most UI toolkit exposes a template engine, like Android layout, iOS Nib, WPF XAML and Qt Qml. You always have a backdoor if you need to code a close to the metal component, so I don't see what coding components in javascript instead of templates buys you in day-to-day usage.

What it buys you in to day to day usage is a full-featured default, not a half measure.

Talking about React specifically, jsx marries the straightforward, easy to understand aspects of templating with the backing of a fully expressive language. It�s easier to make a programming language a good templating language, rather than making a templating language a good programming language.

It means significantly less context switching whilst in front end development, as the template and the supporting code are together like the probably should be, separating features and concerns rather than technology.

It�s a model I believe is unparalleled in web dev as far as productivity, being optimal by default as well which means less tear downs to rewrite with a new approach.

# ? Jan 17, 2018 03:46

Adbot: ADBOT LOVES YOU

# ? Apr 16, 2024 16:53

prom candy: Dec 16, 2005; Only I may dance

The world where designers are coding templates so it makes sense for them to have a simple templating language is the same world where non-technical product people are writing user stories for cucumber.

# ? Jan 18, 2018 06:31

Sedro: Dec 31, 2008

A simple templating language is easier to optimize for.

https://www.youtube.com/watch?v=nXCSloXZ-wc

# ? Jan 18, 2018 16:48

geeves: Sep 16, 2004

Sedro posted:

A simple templating language is easier to optimize for.

https://www.youtube.com/watch?v=nXCSloXZ-wc

I see visuals like the one in the video thumbnail and immediately think I'm going to be listening to psy trance on acid.

# ? Jan 19, 2018 01:06

huhu: Feb 24, 2006

I'm using React and flexbox to create a scrollable grid of divs. When I get to within 200px of the bottom of the page, I do an ajax request for more content to go in the divs. The old and new content together is mapped to a set of divs and all of them are then rendered on the page. Ideally, I'd like the window not to scroll when new content is added but right now the window is scrolling to, what appears to be, random positions on the page. Any thoughts on what I should be looking at to fix this?

Edit: It works just fine if there's only one item per row but not if there is >1 item.

huhu fucked around with this message at 22:57 on Jan 19, 2018

# ? Jan 19, 2018 22:49

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Are the scrolling divs scrolling internally, or is it a full page scroll? At any rate, unless some aspect of your javascript is messing with tho scroll position, it's probably just reflow. It could get weird as well if a single frame in the DOM rewrite removes bottom elements, as that results in the scroll nudging back up and never resetting.

https://httpster.net

Our tactic on this site, because we were scrolling both up and down infinitely, is to stabilise on where the intro statement is (Httpster is an inspiration resource showcasing totally rocking websites made by people from all over the world.) - on every new content load we measure where it is, introduce the new elements, measure it again and then correct the scrollY to match. It's not so great loading upwards, probably need to spend some time fixing it, but going downwards it doesn't miss a trick, although we are working with the DOM directly so we know for a fact no reconciliation is removing nodes below.

Anyway, the possible solution if you can't find the source of your scroll problems, is to measure and restabilise the scroll based on some known thing that's going to be visible both before and after the content load.

# ? Jan 19, 2018 23:48

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

Maluco Marinero posted:

https://httpster.net

Hey. Nice site. Always looking for inspiration.

# ? Jan 20, 2018 04:20

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Thermopyle posted:

Hey. Nice site. Always looking for inspiration.

Thanks! Yeah, it's nice. I helped build the latest iteration of it, my business partner has spent way more time on it in previous iterations and curation and what not.

# ? Jan 20, 2018 04:42

prom candy: Dec 16, 2005; Only I may dance

Okay so let's say I have a component that has some subcomponents and I want to give consumers of the component some ability to control the structure. For example, a NavItem that can also have a SubNav, SubNavSections, and SubNavItems. Should I just export the subcomponents as properties on NavItem so that I can do something like:

code:

<NavItem title="About">
  <NavItem.SubNav>
    <NavItem.SubNavSection title="Subsection">
      <SubNavItem to="/about/1" title="A Sub-Page" />
      <SubNavItem to="/about/2" title="Another Sub-Page" />
    </NavItem.SubNavSection>
  </NavItem.SubNav>
</NavItem>

Alternately, I could use renderProps and pass the components as args. I don't think I've ever seen anyone doing that but I know people have renderProp mania these days:

code:

<NavItem 
  title="About"
  renderSubNav={({ Section, Item }) => (
    <Fragment>
      <Section title="Section One">
        <Item to="/" title="Whatever" />
        <Item to="/yo" title="Hi" />
      </Section>

      <Section title="Section Two">
        <Item to="/" title="Whatever" />
        <Item to="/yo" title="Hi" />
      </Section>
    </Fragment>
  )}
/>

Any thoughts on this? This is coming out of toying around with styled-components, normally I would just do something like this with classNames:

code:

<NavItem title="About">
  <div className="SubNav">
    <div className="SubNav__Section">
      <div className="SubNav__SectionTitle">Section Title</div>
      <Link to="/about/1" className="SubNav__Item">A Sub-Page</Link>
      <Link to="/about/2" className="SubNav__Item">Other Sub-Page</Link>
    </div>
  </div>
</NavItem>

# ? Jan 20, 2018 16:44

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

prom candy posted:

Okay so let's say I have a component that has some subcomponents and I want to give consumers of the component some ability to control the structure. For example, a NavItem that can also have a SubNav, SubNavSections, and SubNavItems. Should I just export the subcomponents as properties on NavItem so that I can do something like:
code:
<NavItem title="About">
  <NavItem.SubNav>
    <NavItem.SubNavSection title="Subsection">
      <SubNavItem to="/about/1" title="A Sub-Page" />
      <SubNavItem to="/about/2" title="Another Sub-Page" />
    </NavItem.SubNavSection>
  </NavItem.SubNav>
</NavItem>
Alternately, I could use renderProps and pass the components as args. I don't think I've ever seen anyone doing that but I know people have renderProp mania these days:
code:
<NavItem 
  title="About"
  renderSubNav={({ Section, Item }) => (
    <Fragment>
      <Section title="Section One">
        <Item to="/" title="Whatever" />
        <Item to="/yo" title="Hi" />
      </Section>

      <Section title="Section Two">
        <Item to="/" title="Whatever" />
        <Item to="/yo" title="Hi" />
      </Section>
    </Fragment>
  )}
/>
Any thoughts on this? This is coming out of toying around with styled-components, normally I would just do something like this with classNames:
code:
<NavItem title="About">
  <div className="SubNav">
    <div className="SubNav__Section">
      <div className="SubNav__SectionTitle">Section Title</div>
      <Link to="/about/1" className="SubNav__Item">A Sub-Page</Link>
      <Link to="/about/2" className="SubNav__Item">Other Sub-Page</Link>
    </div>
  </div>
</NavItem>

I'm not sure what on earth you are actually asking.

# ? Jan 20, 2018 23:56

prom candy: Dec 16, 2005; Only I may dance

Possibly a very dumb question?

# ? Jan 21, 2018 02:52

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

You could build an enum that describes the components you want to render. Then render them based on a prop you pass, if I guessed what the question was I want a pizza.

# ? Jan 21, 2018 05:12

Vincent Valentine: Feb 28, 2006; Murdertime

Edit: woops nevermind ignore me

# ? Jan 21, 2018 07:22

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Questions about Webpack and making a vendor bundle with CommonsChunkPlugin (if that's even what I should use).
If I'm specifying what files go into the bundle, then what is the CommonsChunkPlugin even doing?
Also would I need to still put import $ from jquery at the top of my .js files, or is just having the external reference to vendor.js in the HTML enough?
Source: Webpack Documenation

code:

entry: {
  vendor: ["jquery", "other-lib"],
  app: "./entry"
},
plugins: [
  new webpack.optimize.CommonsChunkPlugin({
    name: "vendor",
    // filename: "vendor.js"
    // (Give the chunk a different name)

    minChunks: Infinity,
    // (with more entries, this ensures that no other module
    //  goes into the vendor chunk)
  })
]

# ? Jan 22, 2018 14:43

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

prom candy posted:

Possibly a very dumb question?

What part of the structure does the consumer want to control, and why? Presentational styling? They get very different functionality by rendering different components? Both? An example use case or two might clarify. Could be as simple as <NavItem>{ children }</NavItem> (but probably not =) but tough to tell w/o more context.

# ? Jan 22, 2018 14:58

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

The Merkinman posted:

Questions about Webpack and making a vendor bundle with CommonsChunkPlugin (if that's even what I should use).
If I'm specifying what files go into the bundle, then what is the CommonsChunkPlugin even doing?
Also would I need to still put import $ from jquery at the top of my .js files, or is just having the external reference to vendor.js in the HTML enough?
Source: Webpack Documenation
code:
entry: {
  vendor: ["jquery", "other-lib"],
  app: "./entry"
},
plugins: [
  new webpack.optimize.CommonsChunkPlugin({
    name: "vendor",
    // filename: "vendor.js"
    // (Give the chunk a different name)

    minChunks: Infinity,
    // (with more entries, this ensures that no other module
    //  goes into the vendor chunk)
  })
]

The CommonsChunkPlugin can do a few things, which is unfortunate, because it makes it confusing. One use of it is to automatically ensure that common code is in the "main" file if you are creating several small bundles to be served async to users as they use your app. So if they have to load 'home.js', 'about.js', and 'fart.js' as they hit those routes in your app, then any code that is in more than one will be moved "up" into the parent bundle for you instead of bloating three bundles. That is not your use case though!

The other thing CommonsChunkPlugin can do for you is to take modules you tell it to and make them their own bundle. This is your use case, and what your example webpack config will do. So when building, if Webpack sees import $ from 'jquery' or import { blah } from 'other-lib' in your code, it will take note to put those imports into the vendor.js file instead of your main bundle. And yes, you will still need to use import statements in your code to use them.

If you don't want to manually add your dependencies in your config, you can just read them out of your package.json like so:

JavaScript code:

// webpack.js


const pkg = require('./package.json');
const deps = Object.keys(pkg.dependencies);

module.exports = {
    entry: {
        bundle: './src/client.js',
        vendor: deps
    },
    // rest of config ....
}

# ? Jan 22, 2018 15:12

huhu: Feb 24, 2006

Maluco Marinero posted:

Are the scrolling divs scrolling internally, or is it a full page scroll? At any rate, unless some aspect of your javascript is messing with tho scroll position, it's probably just reflow. It could get weird as well if a single frame in the DOM rewrite removes bottom elements, as that results in the scroll nudging back up and never resetting.

https://httpster.net

Our tactic on this site, because we were scrolling both up and down infinitely, is to stabilise on where the intro statement is (Httpster is an inspiration resource showcasing totally rocking websites made by people from all over the world.) - on every new content load we measure where it is, introduce the new elements, measure it again and then correct the scrollY to match. It's not so great loading upwards, probably need to spend some time fixing it, but going downwards it doesn't miss a trick, although we are working with the DOM directly so we know for a fact no reconciliation is removing nodes below.

Anyway, the possible solution if you can't find the source of your scroll problems, is to measure and restabilise the scroll based on some known thing that's going to be visible both before and after the content load.

Turns out the data was getting ever so slightly reordered which gave it the appearance of not maintaining proper scroll height or the window kept jumping around to return to the element it was originally at. Not quite sure but it's fixed. Thanks for your help though!

# ? Jan 22, 2018 16:05

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Lumpy posted:

The CommonsChunkPlugin can do a few things, which is unfortunate, because it makes it confusing. One use of it is to automatically ensure that common code is in the "main" file if you are creating several small bundles to be served async to users as they use your app. So if they have to load 'home.js', 'about.js', and 'fart.js' as they hit those routes in your app, then any code that is in more than one will be moved "up" into the parent bundle for you instead of bloating three bundles. That is not your use case though!

The other thing CommonsChunkPlugin can do for you is to take modules you tell it to and make them their own bundle. This is your use case, and what your example webpack config will do. So when building, if Webpack sees import $ from 'jquery' or import { blah } from 'other-lib' in your code, it will take note to put those imports into the vendor.js file instead of your main bundle. And yes, you will still need to use import statements in your code to use them.

If you don't want to manually add your dependencies in your config, you can just read them out of your package.json like so:
JavaScript code:
// webpack.js


const pkg = require('./package.json');
const deps = Object.keys(pkg.dependencies);

module.exports = {
    entry: {
        bundle: './src/client.js',
        vendor: deps
    },
    // rest of config ....
}

OK so actually my specific use case is more like

code:

...
entry: {
  vendor: ["jquery", "other-lib"],
  page1: "./page1",
  page2: "./page2",
  page3: "./page3", 
}
...

But still, I'd put import $ from 'jquery' and/or import blah from 'other-lib' at the top of page1, page2, and page3 (if necessary) as well as have a reference to vendor.js in the HTML and CommonsChunkPlugin will know that import $ from 'jquery' doesn't mean to add it to the file, but look in the separate vendor.js?

Would jquery just be the jquery.min.js I get from their site ( but locally hosted), or would it be the npm package? What's the use case in one vs the other?

# ? Jan 22, 2018 16:27

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

The Merkinman posted:

But still, I'd put import $ from 'jquery' and/or import blah from 'other-lib' at the top of page1, page2, and page3 (if necessary) as well as have a reference to vendor.js in the HTML and CommonsChunkPlugin will know that import $ from 'jquery' doesn't mean to add it to the file, but look in the separate vendor.js?

Correct. You'll still need to import in your code wherever you use those libraries, and Webpack will make sure that the page*.js bundles know about where they live in vendor.js

The Merkinman posted:

Would jquery just be the jquery.min.js I get from their site ( but locally hosted), or would it be the npm package? What's the use case in one vs the other?

I have never used jQuery with webpack (or at all in a while!) but my guess is you'd use the npm module of it: https://www.npmjs.com/package/jquery If you use it as an external script, then all your es6 code will have to magically know that this global variable called "$" exists and not to explode in transpiling.

# ? Jan 22, 2018 17:12

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Lumpy posted:

Correct. You'll still need to import in your code wherever you use those libraries, and Webpack will make sure that the page*.js bundles know about where they live in vendor.js

I have never used jQuery with webpack (or at all in a while!) but my guess is you'd use the npm module of it: https://www.npmjs.com/package/jquery If you use it as an external script, then all your es6 code will have to magically know that this global variable called "$" exists and not to explode in transpiling.

Thank you, turns out I was on the right track!

Lumpy posted:

The CommonsChunkPlugin can do a few things, which is unfortunate, because it makes it confusing.

That is still very true

EDIT: I'd like for us to stop using jQuery too. Having import $ from 'jquery' in the file itself is a good way to tell the developer "hey you should probably refactor this file to not need jQuery".

The Merkinman fucked around with this message at 17:55 on Jan 22, 2018

# ? Jan 22, 2018 17:21

Ahz: Jun 17, 2001; PUT MY CART BACK? I'M BETTER THAN THAT AND YOU! WHERE IS MY BUTLER?!

Switching development mid-stream on a Django/SQL backend over to Firebase/Firestore/NoSQL because I just want everything to work on the backend, be scalable and I'd rather spend time on features over ops.

I'm not crazy am I?

# ? Jan 23, 2018 20:54

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

Ahz posted:

Switching development mid-stream on a Django/SQL backend over to Firebase/Firestore/NoSQL because I just want everything to work on the backend, be scalable and I'd rather spend time on features over ops.

I'm not crazy am I?

Yes you're crazy to tie your app into a third party service like that.

Also, Firebase/Firestore/NoSQL is not a solution to wanting to spend more time on features over not-features.

# ? Jan 23, 2018 21:19

Ahz: Jun 17, 2001; PUT MY CART BACK? I'M BETTER THAN THAT AND YOU! WHERE IS MY BUTLER?!

Aside from the obvious downsides like losing out to relational data and vendor-lockin, why else would you say that?

I have made peace with the idea of losing relational data over just doing pre-calcs on aggregates I need vs. having to babysit a DB, OS patching, logging, replication headaches, backups and inevitable restoration headaches where I don't really care too much about denormalization vs. all the work I save running a production scale app.

# ? Jan 23, 2018 21:29

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

Ahz posted:

Aside from the obvious downsides like losing out to relational data and vendor-lockin, why else would you say that?

I have made peace with the idea of losing relational data over just doing pre-calcs on aggregates I need vs. having to babysit a DB, OS patching, logging, replication headaches, backups and inevitable restoration headaches where I don't really care too much about denormalization vs. all the work I save running a production scale app.

Vendor lockin is a big thing that no one ever thinks is a big thing until it fucks them over.

Try Heroku for Django...not much babysitting DB/OS/replication or backups there.

# ? Jan 23, 2018 21:44

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

Ahz posted:

Aside from the obvious downsides like losing out to relational data and vendor-lockin, why else would you say that?

I have made peace with the idea of losing relational data over just doing pre-calcs on aggregates I need vs. having to babysit a DB, OS patching, logging, replication headaches, backups and inevitable restoration headaches where I don't really care too much about denormalization vs. all the work I save running a production scale app.

Why not use Amazons RDS stuff? Click click click you have a DB.

# ? Jan 23, 2018 22:07

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

Correct me if I'm wrong but a service in Angular 2 is just a piece of code we want to make available in whatever place we import it too, right?

Like if I had something like an API call in a service and wanted to use that API in various places I'd nest it in a service then just call it whenever I wanted too, right?

# ? Jan 23, 2018 22:28

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

Ape Fist posted:

Correct me if I'm wrong but a service in Angular 2 is just a piece of code we want to make available in whatever place we import it too, right?

Like if I had something like an API call in a service and wanted to use that API in various places I'd nest it in a service then just call it whenever I wanted too, right?

Think of the difference as between UI interacting code and non-UI interacting code. Components interact with the user. Services do not, services interact with each-other and components. Ideally, Services should represent 100% of your actual application, and components just manage the interaction between the user and them.

Using a Service to encapsulate an API is a good choice, it will allow you to centralize the API concepts across many components/services.

# ? Jan 23, 2018 22:48

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

I've been tinkering around with a bunch of Webpack plugins because I wanted to get a better idea of how it worked and what it exactly was doing, and there's something that create-react-app is doing in it's webpack config that I just can't figure out for the life of me.

So I get that create-react-app is using the index.html file as a template where they're injecting the css and js files upon building the project with the HTML plugin. But I'm wondering how the js and css files are getting injected upon starting a dev server, and how is there no second index.html file created somewhere that includes the bundle.js and bundle.css in the markup? I'm very lost here. Anyone familiar enough with the build tools to answer?

# ? Jan 24, 2018 11:33

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

Grump posted:

I've been tinkering around with a bunch of Webpack plugins because I wanted to get a better idea of how it worked and what it exactly was doing, and there's something that create-react-app is doing in it's webpack config that I just can't figure out for the life of me.

So I get that create-react-app is using the index.html file as a template where they're injecting the css and js files upon building the project with the HTML plugin. But I'm wondering how the js and css files are getting injected upon starting a dev server, and how is there no second index.html file created somewhere that includes the bundle.js and bundle.css in the markup? I'm very lost here. Anyone familiar enough with the build tools to answer?

The index.html (and bundle files) are all kept in memory when you run the dev server. If you run the 'build' command, you'll get actual files created.

If you want to see exactly what it does, create a new starter project and do yarn eject (or npm run eject I think?) and you'll see their configs and whatnot.

# ? Jan 24, 2018 15:23

Begby: Apr 7, 2005; Light saber? Check. Black boots? Check. Codpiece? Check. He's more machine than kid now.

I am somewhat new to react. I am creating an app that uses react, react-redux, and thunk.

I have a text field and a button. When you click the button it will check if the value is non numeric then raise an error, sorta like this

code:


handleSubmit = event => {
  event.preventDefault();
  if(textIsBad) {
   this.props.raiseError('oh noes!')
  } else {
   this.props.doStuffWithValue(this.state.inputValue)
 }
 this.textFieldRef.focus()
}

The props look kinda like this. Both of these functions are wired up using connect() from react-redux in a container for the component.

code:

TextInputForm.propTypes = {
  raiseError: PropTypes.func.isRequired,
  doStuffWithValue: PropTypes.func.isRequired,
};

doStuffWithValue() makes an api call and updates a list on the page. After it finishes the focus() method is called correctly and everyone is happy.

raiseError() updates a bool called isErrorDialogOpen which is in the redux store. This is tied to a dialog, which is in a different component, that then shows a modal dialog with the error whenever that bool is true. To close the modal dialog, the dialog runs an action which sets the isErrorDialogOpen flag back to false and when the state updates it goes hidden.

What is going wrong though is that when closing the modal dialog error message, focus is not being set on the the ref. I would like to be able to set this up so I can maybe observe the isErrorDialogOpen value and when it flips from true to false it will then set the focus. One option could be to send a callback to raiseError that is then ran when the modal dialog is closed, but I wasn't sure if that was the 'react' way of doing stuff.

The errorDialog is included as a component at the root level and raiseError is used by other components, so this whichever component triggered raiseError should be the component that controls what should happen after the modal dialog is closed.

What is the best approach for this sort of thing?

# ? Jan 24, 2018 17:14

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

Begby posted:

I am somewhat new to react. I am creating an app that uses react, react-redux, and thunk.

I have a text field and a button. When you click the button it will check if the value is non numeric then raise an error, sorta like this
code:
handleSubmit = event => {
  event.preventDefault();
  if(textIsBad) {
   this.props.raiseError('oh noes!')
  } else {
   this.props.doStuffWithValue(this.state.inputValue)
 }
 this.textFieldRef.focus()
}
The props look kinda like this. Both of these functions are wired up using connect() from react-redux in a container for the component.
code:
TextInputForm.propTypes = {
  raiseError: PropTypes.func.isRequired,
  doStuffWithValue: PropTypes.func.isRequired,
};
doStuffWithValue() makes an api call and updates a list on the page. After it finishes the focus() method is called correctly and everyone is happy.

raiseError() updates a bool called isErrorDialogOpen which is in the redux store. This is tied to a dialog, which is in a different component, that then shows a modal dialog with the error whenever that bool is true. To close the modal dialog, the dialog runs an action which sets the isErrorDialogOpen flag back to false and when the state updates it goes hidden.

What is going wrong though is that when closing the modal dialog error message, focus is not being set on the the ref. I would like to be able to set this up so I can maybe observe the isErrorDialogOpen value and when it flips from true to false it will then set the focus. One option could be to send a callback to raiseError that is then ran when the modal dialog is closed, but I wasn't sure if that was the 'react' way of doing stuff.

The errorDialog is included as a component at the root level and raiseError is used by other components, so this whichever component triggered raiseError should be the component that controls what should happen after the modal dialog is closed.

What is the best approach for this sort of thing?

Pass isErrorDialogOpen to your form component, and then you can do something like this:

JavaScript code:

componentDidUpdate( prevProps ) {

     // is modal open now?
     const { isErrorDialogOpen: isOpen } = this.props

     // was it open last update?
     const { isErrorDialogOpen: wasOpen } = prevProps

     if (wasOpen && !isOpen) {
          this.textFieldRef.focus()
     }
}

# ? Jan 24, 2018 17:32

Begby: Apr 7, 2005; Light saber? Check. Black boots? Check. Codpiece? Check. He's more machine than kid now.

Awesome, thanks Lumpy. That works stellar.

It could possible be a problem if I had multiple componenets that could call raiseError that were loaded at the same time. But I don't think that will be an issue for this project so I'll jump off that bridge a different time. (maybe use the callback at that point).

edit: I think the easiest solution there would be to set a flag local to the component like thisComponentRaisedError then add that to the tests to check if that was true also, then flip it to back to false.

Begby fucked around with this message at 17:59 on Jan 24, 2018

# ? Jan 24, 2018 17:54

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

Lumpy posted:

The index.html (and bundle files) are all kept in memory when you run the dev server. If you run the 'build' command, you'll get actual files created.

If you want to see exactly what it does, create a new starter project and do yarn eject (or npm run eject I think?) and you'll see their configs and whatnot.

right. I get that building is actually creating the files.

I have ejected apps and taken a look, but I'm still a bit blurry on this concept, just because Webpack is inherently hard.

My question is, when I start my dev server and index.html loads up, how are the scripts and styles getting injected, if they haven't been build yet?

# ? Jan 24, 2018 20:03

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

Grump posted:

right. I get that building is actually creating the files.

I have ejected apps and taken a look, but I'm still a bit blurry on this concept, just because Webpack is inherently hard.

My question is, when I start my dev server and index.html loads up, how are the scripts and styles getting injected, if they haven't been build yet?

It builds them in memory as part of its startup.

# ? Jan 24, 2018 20:20

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

Grump posted:

right. I get that building is actually creating the files.

I have ejected apps and taken a look, but I'm still a bit blurry on this concept, just because Webpack is inherently hard.

My question is, when I start my dev server and index.html loads up, how are the scripts and styles getting injected, if they haven't been build yet?

The bundle(s) are built and assigned to variables when the server starts, and so are kept in memory. When you make a request to that server, it dynamically generates the response using that bundle. There are no files at all when you run the dev server.

So basically the dev server looks like this:

code:

// on start up...
const bundle = webpack.doWhatYouDoToMakeABundle();


// Pretend this is a web server and that 
// this function listens for any / all requests
handleRoute('*') => (
   return generateHTMLWithBundle( bundle );
)

# ? Jan 25, 2018 18:01

prom candy: Dec 16, 2005; Only I may dance

So gatsby is pretty drat cool, as is netlify. This jamstack stuff is exciting, I'm so sick of babysitting servers and server side code.

# ? Jan 25, 2018 18:32

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

An interesting Node situation has come up at work. Unit tests involving promises fail like so...

code:

TypeError: this._methodBeingTested(...).then(...).finally is not a function

...but only when run with NodeJS v6.2.2. When I run these same tests locally on the slightly-newer v6.11.3, they pass just fine! Same dependencies, same node_modules/ contents (I initially installed them with v6.11.3 and didn't bother reinstalling after using nvm to switch to v6.2.2)...what the gently caress? :argh:

Any ideas on how I might effectively troubleshoot this? I suspect it might be some kind of issue with polyfills (we use babel-register with Mocha) but it's so weird that they'd break across minor revisions of the same Node engine :iiam:

# ? Jan 25, 2018 19:19

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

code:

import { FuckAngular2 } from '@angular/core';

Can someone please unfuck communication from child to parent inter-componental communication for me?

lets imagine I have a parent component, lets say:

code:

export class Parent {

private shitBalls: boolean = true;

}

How do I make the child class change the value of the shitBalls property to false? I wish I could remote into my work machine and grab the code for an example but I can't, but basically I want to change the value of a property in the parent class to false based on, say, a button click in the child component's html template.

# ? Jan 26, 2018 00:28

lunar detritus: May 6, 2009

Ape Fist posted:

code:
import { FuckAngular2 } from '@angular/core';
Can someone please unfuck communication from child to parent inter-componental communication for me?

lets imagine I have a parent component, lets say:
code:
export class Parent {

private shitBalls: boolean = true;

}
How do I make the child class change the value of the shitBalls property to false? I wish I could remote into my work machine and grab the code for an example but I can't, but basically I want to change the value of a property in the parent class to false based on, say, a button click in the child component's html template.

Angular gives you Inputs and Outputs. Your child component should receive shitBalls through an input, do whatever it needs to it and then return the new value as an output event which needs to be caught by the parent component.

This tutorial by Todd Motto looks good.

# ? Jan 26, 2018 02:15

Adbot: ADBOT LOVES YOU

# ? Apr 16, 2024 16:53

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

Ape Fist posted:

code:
import { FuckAngular2 } from '@angular/core';
Can someone please unfuck communication from child to parent inter-componental communication for me?

lets imagine I have a parent component, lets say:
code:
export class Parent {

private shitBalls: boolean = true;

}
How do I make the child class change the value of the shitBalls property to false? I wish I could remote into my work machine and grab the code for an example but I can't, but basically I want to change the value of a property in the parent class to false based on, say, a button click in the child component's html template.

Short answer is components shouldn't ever do that. There are two ways in which it can be considered acceptable.

1) You pass a function to the child which will facilitate this change. This prevents the child from actually having details about the parent, and simply interacts with it via well defined callbacks.

2) You would store this value in a service, not the parent, and both would have access to the service. Ideally, again, via functions instead of directly changing the fields.

# ? Jan 26, 2018 04:14

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

«‹›234 »