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 »

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

The Merkinman posted:

Angular 2.0 is now in beta
Given this is Google, it will be out of beta in, what, 3 years?

As opposed to React still being 0.1x after almost 3 years?

# ? Dec 15, 2015 22:02

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 20:34

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

It's almost as if version numbers are meaningless tags in most cases*. I loved to mess with the one Mac user I knew in college by asking about what cool new things came in the latest OSX service pack

*Elm, for example, makes the major version part of the package interface and enforces that so you have to up the version if you break the interface, which is pretty neat

# ? Dec 15, 2015 22:39

consensual poster: Sep 1, 2009

The Merkinman posted:

Angular 2.0 is now in beta
Given this is Google, it will be out of beta in, what, 3 years?

I assume you know nothing about Angular or its history? The RC will be in 6 months or less. 3 years ago, Angular was barely out of the 1.0 release and it has been very actively maintained and updated since then. They will be releasing 1.5 very soon. Oh, and the version numbers here are not at all insignificant. The 2.x releases will be a major departure from the 1.x line and quite deserving of the major version number update.

Munkeymon posted:

*Elm, for example, makes the major version part of the package interface and enforces that so you have to up the version if you break the interface, which is pretty neat

That is awesome and I wish it was a more common feature.

I'm learning a bit more about React lately and I'm a bit confused by why JSX exists. There are several talks in which the React designers say that they believe it is better to write templates in JavaScript. However, they also realize that this isn't really feasible for teams where designers who only have familiarity with HTML are often required to edit templates. So they invent JSX, which is an HTML-like DSL that is transformed into JS. Why make an HTML-like DSL instead of just using HTML with a compilation step? Wouldn't that be easier than forcing a designer to learn the quirks of how JSX differs from HTML? In fact there are libraries like t7 (https://github.com/trueadm/t7) that can take template strings and turn them into React-compliant virtual DOM objects. Why would anyone want to use JSX?

# ? Dec 16, 2015 09:58

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

Perfectly Cromulent posted:

Why would anyone want to use JSX?

Because I find it a lot faster to write and a ton easier to read.

# ? Dec 16, 2015 16:53

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

Skandranon posted:

As opposed to React still being 0.1x after almost 3 years?

Perfectly Cromulent posted:

I assume you know nothing about Angular or its history? The RC will be in 6 months or less. 3 years ago, Angular was barely out of the 1.0 release and it has been very actively maintained and updated since then. They will be releasing 1.5 very soon. Oh, and the version numbers here are not at all insignificant. The 2.x releases will be a major departure from the 1.x line and quite deserving of the major version number update.

I just meant it as a joke about how Google has their products in beta for a long period of time

# ? Dec 16, 2015 17:14

luchadornado: Oct 7, 2004; A boombox is not a toy!

Perfectly Cromulent posted:

Why would anyone want to use JSX?

Like Lumpy said, React is way faster/easier to use once you learn it, and the learning curve is ridiculously small. It's not like learning XSLT or something - it's essentially HTML with a few quirks like 'className' instead of 'class' attributes. Being scared of transpiling things is a legit concern at first, but in 2015 you should really embrace a tool like Gulp to do easy transpiling/minification/combining for any front-end design.

# ? Dec 16, 2015 17:35

Strong Sauce: Jul 2, 2003; You know I am not really your father.

What is the best way to test React? Facebook recommends Shallow Component Rendering with Jest but I spent like 2 hours last night trying to figure out how to work it with Babel/React, then spent a whole bunch more time trying to figure out why the test kept failing (HINT: a space " " counts as a completely different child from the previous word).

Is there a better way to do this? Or is this just a huge pain in the butt in general?

# ? Dec 16, 2015 18:30

NovemberMike: Dec 28, 2008

Thermopyle posted:

Yeah, it took me awhile to get past that feeling. Sometimes a components state is just a components state, man!

This is really important, stateless components are cool but some things are stateful and trying to remove the state will be more complicated than just going with it. Hammers for nails and screwdrivers for screws instead of hammers for everything, if that makes sense.

# ? Dec 16, 2015 20:36

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

Strong Sauce posted:

What is the best way to test React? Facebook recommends Shallow Component Rendering with Jest but I spent like 2 hours last night trying to figure out how to work it with Babel/React, then spent a whole bunch more time trying to figure out why the test kept failing (HINT: a space " " counts as a completely different child from the previous word).

Is there a better way to do this? Or is this just a huge pain in the butt in general?

I've found Mocha + Enzyme to be pretty straightforward (and much, much faster than Jest). Here's how it handles shallow rendering, via the Enzyme docs:

JavaScript code:

import { shallow } from 'enzyme';
import sinon from 'sinon';

describe('<MyComponent />', () => {

  it('renders three <Foo /> components', () => {
    const wrapper = shallow(<MyComponent />);
    expect(wrapper.find(Foo)).to.have.length(3);
  });

  it('renders an `.icon-star`', () => {
    const wrapper = shallow(<MyComponent />);
    expect(wrapper.find('.icon-star')).to.have.length(1);
  });

  it('renders children when passed in', () => {
    const wrapper = shallow(
      <MyComponent>
        <div className="unique" />
      </MyComponent>
    );
    expect(wrapper.contains(<div className="unique" />)).to.be.true;
  });

  it('simulates click events', () => {
    const onButtonClick = sinon.spy();
    const wrapper = shallow(
      <Foo onButtonClick={onButtonClick} />
    );
    wrapper.find('button').simulate('click');
    expect(onButtonClick.calledOnce).to.be.true;
  });

});

EDIT: Also, you can run Mocha with --compilers js:babel-core/register to make it use Babel.

Depressing Box fucked around with this message at 21:23 on Dec 16, 2015

# ? Dec 16, 2015 20:58

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Seconding Mocha with Enzyme. It's super nice.

# ? Dec 17, 2015 02:50

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Yeah seems faster with the shallow rendering. However I'm still running into a problem (seems react related though) where if you have something like

code:

<span>HELLO </span>

where there is a space after "HELLO", it turns it into two children, so you can't do this:

code:

expect([wrapper.props().children).to.deep.equal([
  <span>HELLO </span>
])

since it doesn't recognize it as two children in the comparison.

Strong Sauce fucked around with this message at 02:57 on Dec 17, 2015

# ? Dec 17, 2015 02:55

abraham linksys: Sep 6, 2010

tangential to the current discussion: having done React TDD at my last gig, and now working on a codebase where I haven't written any tests for components (just Flux stores)...

React testing frustrates me because the declarative nature of React makes certain guarantees on your code. I wouldn't, for example, write a test like "renders elements passed in," or "has a click handler," for the same reason I wouldn't write tests making sure my CSS rules made an element red - there's no logic to test there. The tests that I wrote at my last gig were pre-Flux, so they were testing things like complex action/state code inside components, and obviously if you have that you want to test your components. But when they're basically blobs of JSX that render props and maybe have an event handler that calls a Flux action... I dunno, it just seems like pointless boilerplate.

Y'all who do write tests for components, how do you scope it?

# ? Dec 17, 2015 03:00

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

I think a possibly better way to approach this is to have a good workspace for viewing components in isolation. My process is to run a gulp task that collects all files I determine to be exporting react components, (*.dom.jsx or something), matches them with test data that's side by side (ie *.data.js) and then renders out the html. If I need to test the behaviour too then I mount the component over the top in the browser.

This workflow means I can inspect the results where it counts, and potentially set up screenshot testing. That said though, you could probably get some value out of saving the html and doing diff testing on that so you get a cheap test that should catch any unexpected regressions while making updating the tests cheap.

# ? Dec 17, 2015 03:44

luchadornado: Oct 7, 2004; A boombox is not a toy!

abraham linksys posted:

I dunno, it just seems like pointless boilerplate.

Y'all who do write tests for components, how do you scope it?

I think your earlier statement is the answer to your question. There's an unfortunate pendulum swing of "we need 100% code coverage" from "we don't need to write tests". Sometimes poo poo doesn't need to have unit tests written. For all my React stuff, I rely purely on regression testing - does the page render, and do my X most important use cases work as expected. That's just my take though, and I'm still interested in the other side of the discussion.

edit: for reference, one of my React web apps sees ~30,000 uniques/month, and the other 3-4 are admin tools used to drive pages that see millions of uniques/month. So it's not like these are projects sitting on my personal site with next to no traffic.

luchadornado fucked around with this message at 14:08 on Dec 17, 2015

# ? Dec 17, 2015 14:06

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

I feel like most of my React components don't need any unit tests as almost all the logic of my apps live elsewhere.

I might do higher level integration or functional testing that tests the output of the components in context like with screenshot testing or looking at the raw HTML or something.

# ? Dec 17, 2015 15:59

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Test the data that should feed into your React components. If you want integration testing, test whether your components render the data they should be fed. Otherwise, you're just testing React.

# ? Dec 17, 2015 18:28

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Yeah testing components seems kinda dumb if all they're spewing is some extra HTML. The only one I've needed to really test so far is my pagination component which has a lot more logic in it than my other components. It just seems like something needed so you can say here are some tests.

# ? Dec 17, 2015 20:33

Strong Sauce: Jul 2, 2003; You know I am not really your father.

So I'm kinda stuck, I'm trying to mock a component that runs a $.ajax call. When I try to just "import X from 'X'", I get an error from $.ajax saying a.document is trying to access an undefined variable (a). Is there anyway in sinon so that when it sees the import call it just mocks it? I apparently cannot preemptively mock it like you can in jester it seems. I'm not too familiar though with sinon so I don't know if I'm doing it right or if its possible.

# ? Dec 18, 2015 03:42

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

Strong Sauce posted:

So I'm kinda stuck, I'm trying to mock a component that runs a $.ajax call. When I try to just "import X from 'X'", I get an error from $.ajax saying a.document is trying to access an undefined variable (a). Is there anyway in sinon so that when it sees the import call it just mocks it? I apparently cannot preemptively mock it like you can in jester it seems. I'm not too familiar though with sinon so I don't know if I'm doing it right or if its possible.

We use a library called Mockery to do that. Maybe it'd help?

# ? Dec 18, 2015 04:39

Strong Sauce: Jul 2, 2003; You know I am not really your father.

I don't need a mocking library (sinon does that) but the import call is made in the actual component (not the test file) and it doesn't seem to mock it while its in another file.

# ? Dec 18, 2015 05:39

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

Can you move the ajax call into a separate method and pass it to the component as a prop? Then all the component expects is a PropTypes.func called getPosts() that returns a promise (or something along those lines).

# ? Dec 18, 2015 05:53

NovemberMike: Dec 28, 2008

abraham linksys posted:

tangential to the current discussion: having done React TDD at my last gig, and now working on a codebase where I haven't written any tests for components (just Flux stores)...

React testing frustrates me because the declarative nature of React makes certain guarantees on your code. I wouldn't, for example, write a test like "renders elements passed in," or "has a click handler," for the same reason I wouldn't write tests making sure my CSS rules made an element red - there's no logic to test there. The tests that I wrote at my last gig were pre-Flux, so they were testing things like complex action/state code inside components, and obviously if you have that you want to test your components. But when they're basically blobs of JSX that render props and maybe have an event handler that calls a Flux action... I dunno, it just seems like pointless boilerplate.

Y'all who do write tests for components, how do you scope it?

I feel like in general people that do TDD can tend to test too much. High value tests will verify that nothing important breaks, and in a react app I'd generally consider the store updates, state changes for complex components and ajax calls to be the important things. Test those and I doubt you'll run into any huge problems that more tests would have helped on.

# ? Dec 18, 2015 08:02

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Depressing Box posted:

Can you move the ajax call into a separate method and pass it to the component as a prop? Then all the component expects is a PropTypes.func called getPosts() that returns a promise (or something along those lines).

Just tried to do this, it seems like for whatever reason when jQuery is imported, it creates an IIFE with either "window" or "this" as the 1st parameter depending on whether or not the global window exists. It doesn't in node.js so it should just default to "this" which should be {} but it instead returns undefined.

This. is. kinda. annoying.

Edit: This is pretty close to the code that causes my test to choke

code:

;(function(a,b) {
  module.exports =  (a.document ? b(a) : {})
})(typeof window != "undefined" ? window : this, function(window, c) { console.log("window:", w) })

If you require this from another file it executes just fine... but I think its something in babel/react that's loving with it.

Strong Sauce fucked around with this message at 09:08 on Dec 18, 2015

# ? Dec 18, 2015 08:50

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Welp, just compiled out the .jsx file. It's definitely... either enzyme, react, or babel causing these fuckups... wonderful.

# ? Dec 18, 2015 10:08

Mr Shiny Pants: Nov 12, 2012

Elm is the poo poo, I haven't had this much fun writing webpages since whenever. Thanks to the guy posting the video, you rock!

Fsharp syntax for webpages, what is not to like

# ? Dec 18, 2015 23:01

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

Strong Sauce posted:

Welp, just compiled out the .jsx file. It's definitely... either enzyme, react, or babel causing these fuckups... wonderful.

I did some looking, and it's probably related to jQuery's issues running in a non-browser (Node.js) environment, as covered in this blog post. I also put together a few tests to better show the issue and some possible solutions:

https://github.com/oepn/react-jquery-tests

Personally, I recommend making Ajax calls outside of your components, and generally keeping jQuery away from any code you want to test.

EDIT: You can also use enzyme's describeWithDOM() and mount() methods to instantiate a virtual DOM, which uses slightly less code.

Depressing Box fucked around with this message at 21:11 on Dec 20, 2015

# ? Dec 20, 2015 06:01

Kekekela: Oct 28, 2004

Depressing Box posted:

I did some looking, and it's probably related to jQuery's issues running in a non-browser (Node.js) environment

Not sure if it'll work for this particular situation but I've used cheerio in the past to get jQuery functionality in a node environment. Its funny though because that was before I got on my "plain JS over jQuery" kick so if I approached the same problem now I'm not sure I'd even need it.

# ? Dec 20, 2015 11:07

luchadornado: Oct 7, 2004; A boombox is not a toy!

I am excited for the day I finally remove the last traces of jQuery in all my code. It served its purpose (in 2009), but we live in a different age.

http://youmightnotneedjquery.com/

# ? Dec 20, 2015 15:23

abraham linksys: Sep 6, 2010

I've stripped jQuery out of my React apps (I think, should probably inspect my webpack bundle to make sure some dep didn't sneak it back in there)

$.ajax was the big remaining holdout, and window.fetch is still a garbage-tier API (hope you bring your own query-string library for GET requests!! :downs:

) but is at least better than XMLHTTPRequest unless you need to abort requests (which I don't think $.ajax let you do anyways?)

# ? Dec 21, 2015 00:30

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

On that note, does anyone have any recommendations for a good, browser-friendly request library? My current project is only using jQuery for $.ajax, and it's modular enough that I could swap it out with anything that returns a promise.

# ? Dec 21, 2015 01:25

YO MAMA HEAD: Sep 11, 2007

I started using the Fetch API for a project that's already locked in to Firefox/Chrome (re: getUserMedia support�thanks, Safari). I was very excited about it until I needed to monitor upload progress, which still requires an XHR.

# ? Dec 21, 2015 02:12

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

XMLHttpRequest isn't that bad an API. I actually believe that, I mean you'll always wrap it so you can just use myAPI.get, but there's nothing inherently wrong with the API that makes it unusable, and request wrappers I find always gently caress something up, like swallowing CORS errors or just not exposing enough of the underlying API causing it to be useless if you're making certain requests.

# ? Dec 21, 2015 07:09

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Depressing Box posted:

I did some looking, and it's probably related to jQuery's issues running in a non-browser (Node.js) environment, as covered in this blog post. I also put together a few tests to better show the issue and some possible solutions:

https://github.com/oepn/react-jquery-tests

Personally, I recommend making Ajax calls outside of your components, and generally keeping jQuery away from any code you want to test.

EDIT: You can also use enzyme's describeWithDOM() and mount() methods to instantiate a virtual DOM, which uses slightly less code.

I ended up just going with what you mentioned (passing $/jQ object thru props) then actually just wrote my own $/jQ object in the test. Pretty obvious in hindsight. Thanks for that link though since _it_ still prevents me from doing any kind of dom rendering.

# ? Dec 21, 2015 08:35

luchadornado: Oct 7, 2004; A boombox is not a toy!

Depressing Box posted:

On that note, does anyone have any recommendations for a good, browser-friendly request library? My current project is only using jQuery for $.ajax, and it's modular enough that I could swap it out with anything that returns a promise.

There are three recommendations right at the top of the youmightnotneedjquery.com page. I ended up just writing my own.

# ? Dec 21, 2015 15:02

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Depressing Box posted:

On that note, does anyone have any recommendations for a good, browser-friendly request library? My current project is only using jQuery for $.ajax, and it's modular enough that I could swap it out with anything that returns a promise.

Axios if you want promises, and superagent if you want callbacks.

# ? Dec 22, 2015 03:46

an skeleton: Apr 23, 2012; scowls @ u

Management recently handed down the decision to go with a type-based (rather than feature etc.) based folder structure for our Angular app. I don't like it but I want to know other people's opinions. Thoughts?

# ? Dec 22, 2015 05:18

Sedro: Dec 31, 2008

Let management write the code, then.

# ? Dec 22, 2015 05:34

Odette: Mar 19, 2011

What the gently caress is type-based folder structure? Something like css/ js/ html/ img/ objectX/ objectY/?

# ? Dec 22, 2015 05:36

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

Chenghiz posted:

Axios if you want promises, and superagent if you want callbacks.

Or reqwest if you want both!

# ? Dec 22, 2015 05:37

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 20:34

Strong Sauce: Jul 2, 2003; You know I am not really your father.

an skeleton posted:

Management ... Thoughts?

Why are they deciding this? Why would they even have an opinion about this?

# ? Dec 22, 2015 05:50

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

«‹›235 »