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 »

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

I bet there's more failed companies that used Angular than Vue though so you could try and sell them on that.

# ? Feb 19, 2018 03:12

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 12:30

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

Nolgthorn posted:

I bet there's more failed companies that used Angular than Vue though so you could try and sell them on that.

Only because Angular has been around long enough to be associated with more failed companies.

# ? Feb 19, 2018 04:01

Tres Burritos: Sep 3, 2009

# ? Feb 19, 2018 13:34

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

gmq posted:

Google finally confirmed what everyone already knew: AngularJS is dead(-ish).

Since I don't know Angular's ecosystem well, they are just killing the 1.x version, and there's still two other versions (2 and ??) out there? Plus the article links to something called "The Angular Platform": is that the '??' version or is that something new?

I take it it's hard to migrate to 2 or ?? if you had a 1.x codebase?

# ? Feb 19, 2018 15:34

darthbob88: Oct 13, 2011; YOSPOS

Lumpy posted:

Since I don't know Angular's ecosystem well, they are just killing the 1.x version, and there's still two other versions (2 and ??) out there? Plus the article links to something called "The Angular Platform": is that the '??' version or is that something new?

I take it it's hard to migrate to 2 or ?? if you had a 1.x codebase?

Yeah, AngularJS is 1.x, 2/4/5 will still be under development, and the Angular Platform, AFAIK, is just Angular for PWAs. Dunno how hard it is to migrate, I just rewrote everything when I moved off AngularJS.

# ? Feb 19, 2018 16:00

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

A good prank is to label four Angulars 1, 2, 4, and 5, let them loose in a hipster startup office, and they'll spend the entire day looking for Angular 3.

# ? Feb 19, 2018 17:02

Shy: Mar 20, 2010

It's how software is numbered nowadays, hipsters won't even know the right order.

# ? Feb 19, 2018 17:34

lunar detritus: May 6, 2009

Lumpy posted:

I take it it's hard to migrate to 2 or ?? if you had a 1.x codebase?

It depends. If your app is a SPA or SPA-ish it's somewhat easy (besides the typescript/rxjs learning curve). If it isn't (Rails + AngularJS for small widgets, for example) you're screwed.

lunar detritus fucked around with this message at 18:47 on Feb 19, 2018

# ? Feb 19, 2018 17:54

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

Pollyanna posted:

A good prank is to label four Angulars 1, 2, 4, and 5, let them loose in a hipster startup office, and they'll spend the entire day looking for Angular 3.

# ? Feb 19, 2018 18:36

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.

AngularJS is on version 1.6, 1.7 is due to be released relatively soon. It will then go into 'Long term support', i.e. be wound down. AngularJS 1.4 was a heavy re-write of the AngularJS core and many methods used pre 1.4 will not work post 1.6, or work less effectively.

Angular 2 was a ground-up rebuild of the Angular Framework and it is coded in a way that is almost entirely different than Angular JS, it uses TypeScript which implements things like static typing, duck typing, and object oriented class methods & interfaces.

Angular 2 has had successive versions, i.e. 4.0, and 5.0 these are incorrectly named 'Angular 4, and Angular 5.' Angular 2, however, is also incorrectly named 'Angular 2'. It is, correctly named 'Angular 2.0', and 'Angular 4.0', and 'Angular 5.0', etc Angular 3.0 was just around the corner but Google lost it down the back of the couch and pulled a cool Microsoft/Apple brand thing where they skipped a number for no loving reason which in turn increased the confusion surrounding the whole thing.

To avoid this confusing moving forward, Google has simple named the framework 'Angular'.

This is meaningless however, as everyone is still confused about the name and will be forever.

Long story short there are two Angulars: 'AngularJS' (v1.6), and 'Angular' (v5.1)

You should learn 'Angular' (v5.1). The 'Hero Walkthrough' gives you a good general overview of the Framework but it doesn't necessarily do a great job of implementing design methods that're common with Angular but it's a good high level overview: https://angular.io/

Ape Fist fucked around with this message at 20:44 on Feb 19, 2018

# ? Feb 19, 2018 20:41

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.

The best thing is when you pulled something out via a GET, pushed it through an interface, fiddled with it in the logic in a hundred different places, then push it back out into a POST through another interface only to realize at some point your component logic turned something from a string into a number and now NPM is making GBS threads itself and returning a hundred errors and your template seems to be broken for absolutely no loving reason because the [(ngModel)] is having an argument with one of the hundred other binding properties you've stuffed into an <input> tag. Plus you forgot to really add any kind of lazy-loading functionality to your project which now has somewhere along the lines of about 500 individual modules all of whom have about 10 imports, and those 10 imports have at least 3 or 4 imports themselves so even though you're loading a page that really has nothing more than a single block of text on it (which naturally you retrieved from the server through an API pull) you've actually basically loaded the entire application which took 15 solid seconds because main.js alone is about 50mb and this is because several of your fellow developers felt it necessary to import entire 3rd party libraries in order to add a single component of functionality to a module they were working on like installing NPM's NKDatePickerModule despite Angular already having a datePicker module which works just fine.

Ape Fist fucked around with this message at 20:57 on Feb 19, 2018

# ? Feb 19, 2018 20:49

fantastic in plastic: Jun 15, 2007; The Socialist Workers Party's newspaper proved to be a tough sell to downtown businessmen.

Is there a good crash course on UX basics?

I'm interviewing in a week and one of the interviewers is a UX designer, so I assume that's what they're going to want to ask me about.

# ? Feb 19, 2018 21:57

darthbob88: Oct 13, 2011; YOSPOS

Ape Fist posted:

Angular 2 has had successive versions, i.e. 4.0, and 5.0 these are incorrectly named 'Angular 4, and Angular 5.' Angular 2, however, is also incorrectly named 'Angular 2'. It is, correctly named 'Angular 2.0', and 'Angular 4.0', and 'Angular 5.0', etc Angular 3.0 was just around the corner but Google lost it down the back of the couch and pulled a cool Microsoft/Apple brand thing where they skipped a number for no loving reason which in turn increased the confusion surrounding the whole thing.

This is actually because Angular is/would be released as separate libraries with synchronous version numbers, so a project would use @angular/core 2.X, @angular/http 2.X, etc. Unfortunately, Angular router was already on v3 when the rest was on v2, and it would have looked stupid to use separate version numbers for everything, so they just skipped from Angular 2.x to 4.x, because that's less stupid.

# ? Feb 19, 2018 22:14

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.

darthbob88 posted:

This is actually because Angular is/would be released as separate libraries with synchronous version numbers, so a project would use @angular/core 2.X, @angular/http 2.X, etc. Unfortunately, Angular router was already on v3 when the rest was on v2, and it would have looked stupid to use separate version numbers for everything, so they just skipped from Angular 2.x to 4.x, because that's less stupid.

Oh yeah the Router module was on 3.0 or something wasn't it, lol.

# ? Feb 19, 2018 22:17

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

Ape Fist posted:

The best thing is when you pulled something out via a GET, pushed it through an interface, fiddled with it in the logic in a hundred different places, then push it back out into a POST through another interface only to realize at some point your component logic turned something from a string into a number and now NPM is making GBS threads itself and returning a hundred errors and your template seems to be broken for absolutely no loving reason because the [(ngModel)] is having an argument with one of the hundred other binding properties you've stuffed into an <input> tag. Plus you forgot to really add any kind of lazy-loading functionality to your project which now has somewhere along the lines of about 500 individual modules all of whom have about 10 imports, and those 10 imports have at least 3 or 4 imports themselves so even though you're loading a page that really has nothing more than a single block of text on it (which naturally you retrieved from the server through an API pull) you've actually basically loaded the entire application which took 15 solid seconds because main.js alone is about 50mb and this is because several of your fellow developers felt it necessary to import entire 3rd party libraries in order to add a single component of functionality to a module they were working on like installing NPM's NKDatePickerModule despite Angular already having a datePicker module which works just fine.

There is a lot of frustration coming from this post. Let me address some of it:

quote:

your component logic turned something from a string into a number

I'm interested to hear a use case where someone thought this was a good idea. It's not. Typescript has types for a reason. If you are needing to cast, then you might need to evaluate how they are stored in the first place. The best rule of thumb I have heard for most things is simply: "if you are going to be performing math on it - it's a number of some sort. Otherwise - it is a string. Period." Ergo - US Zip Codes for example are strings. Same with phone numbers. I can't count the number of times I have had to argue this point with some database designer or back-end engineer.

If your use-case was "because it saves me from having to <insert small conversion/display related task here>" then you are likely already aware that it''s not "saving" you much of anything now.

The rest of your problem seems to be more of an overall design issue. How small are your components? I'm guessing nowhere NEAR small enough. It took me a couple of apps coming from ng1 into ng2 to realize that components need to be tiny. We're talking like <50 lines here. Definitely less than 100 lines. Components should be tiny, very dumb, and reusable. There are bound to be ways you can break up what you got, particularly if one piece of data is going through so many manipulations that you literally can't find the place where a string got converted to a number. Also: turn OFF typescript's duck typing so that you must be explicit about everything. Whine whine extra typing, blah blah blah I know. But I'd also wager that wherever this is happening, someone's not being explicit enough with the typing, hence the problem. (And no - don't just turn it off then go through and type everything not explicit as any, either. That's not going to help.

I realize you're exaggerating somewhat, but what on earth are you binding to on an <input> that you have so many bound properties?

# ? Feb 19, 2018 22:17

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.

My post is largely a combination of several problems I've come across individually while learning Angular which I've overcome. It was mostly for the funnies good buddy. :downs:

Typecasting problems mostly result from the back-end developer being a dope. He had one API which when used with a GET produced a number, but the same property which, when modified and submitted to the outgoing POST wanted a string.

Also, I've had [(ngModel)] do some honestly weird poo poo which has resulted in me having to separate the shorthand into [value] and (ngModel) before.

Ape Fist fucked around with this message at 22:51 on Feb 19, 2018

# ? Feb 19, 2018 22:45

lunar detritus: May 6, 2009

Ape Fist posted:

Also, I've had [(ngModel)] do some honestly weird poo poo which has resulted in me having to separate the shorthand into [value] and (ngModel) before.

I solved that by never ever using ngModel. :v:

# ? Feb 19, 2018 22:54

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

Ape Fist posted:

Typecasting problems mostly result from the back-end developer being a dope. He had one API which when used with a GET produced a number, but the same property which, when modified and submitted to the outgoing POST wanted a string.

An API worthy of the coding horrors thread.

# ? Feb 20, 2018 05:52

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

Anyone have experience with react apps and Jest testing with async functions?

I'm trying do a smoke test on my component, but I have a API call in componentDidMount(), so I'm getting a network request error

my component looks like this

JavaScript code:

export default class Foo extends Component{
  componentDidMount = () => {
      API.getSettings().then(data => console.log(data));
  }
}

and my test looks like

JavaScript code:

it('renders without crashing', () => {
    shallow(<VerifyModal/>);
});

So my test will pass, but I keep getting a "TypeError: Network request failed"

I'm not really sure how to get around this.

# ? Feb 20, 2018 21:39

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

You probably need to use some kind of mocking solution depending on how that API object is getting into your component: https://facebook.github.io/jest/docs/en/mock-functions.html

# ? Feb 20, 2018 21:58

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

Grump posted:

Anyone have experience with react apps and Jest testing with async functions?

I'm trying do a smoke test on my component, but I have a API call in componentDidMount(), so I'm getting a network request error

my component looks like this
JavaScript code:
export default class Foo extends Component{
  componentDidMount = () => {
      API.getSettings().then(data => console.log(data));
  }
}
and my test looks like
JavaScript code:
it('renders without crashing', () => {
    shallow(<VerifyModal/>);
});
So my test will pass, but I keep getting a "TypeError: Network request failed"

I'm not really sure how to get around this.

I'm sure you have but read this first: https://facebook.github.io/jest/docs/en/tutorial-async.html

You can also use nock to mock out requests if you need that.

You can also "replace" imported modules in your test with mocks you write if you want: https://facebook.github.io/jest/docs/en/manual-mocks.html This is probably what you want?

I also find that when something is hard to test, it's because I haven't architected / implemented it as well as it should be. If you make the function a prop you pass in, then you just pass in a jest.mock function and you can verify it's called w/ no API business.

EDIT: Here's a good link I found that may be more helpful then the Jest docs: https://github.com/nilshartmann/jest-playground

EDIT 2: Also, I was under the impression that 'shallow' didn't call any lifecycle methods... are you using enzyme's shallow?

Lumpy fucked around with this message at 22:06 on Feb 20, 2018

# ? Feb 20, 2018 21:59

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

Ape Fist posted:

My post is largely a combination of several problems I've come across individually while learning Angular which I've overcome. It was mostly for the funnies good buddy.

Typecasting problems mostly result from the back-end developer being a dope. He had one API which when used with a GET produced a number, but the same property which, when modified and submitted to the outgoing POST wanted a string.

Also, I've had [(ngModel)] do some honestly weird poo poo which has resulted in me having to separate the shorthand into [value] and (ngModel) before.

Ah okay. I'm imagining the terrible decision which went into him making that back end behave that way.

gmq posted:

I solved that by never ever using ngModel.

Yeah now that I am thinking about it - I rarely use ngModel myself.

# ? Feb 21, 2018 03:34

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

Lumpy posted:

I also find that when something is hard to test, it's because I haven't architected / implemented it as well as it should be. If you make the function a prop you pass in, then you just pass in a jest.mock function and you can verify it's called w/ no API business.

Would dependency injection have any value here beyond just making this component easier to test? Or is making it easier to test value enough in your opinion?

# ? Feb 21, 2018 05:05

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

prom candy posted:

Would dependency injection have any value here beyond just making this component easier to test? Or is making it easier to test value enough in your opinion?

It's a general best practice thing, it's a step toward keeping things loosely coupled. (But yes, one of the major things this benefits is testability).

# ? Feb 21, 2018 06:16

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

Being easy to test means you have good, easy to use and expand architecture, and having good, easy to use architecture means it's easy to test.

(generally)

# ? Feb 21, 2018 08:04

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

Code should never be adapted just so that you can run tests on it, you shouldn't have an `isTest` boolean anywhere or things like that. However if you're not able to test code effectively then it's probably too tightly coupled with other code and should be adapted for that reason.

I see no problem with passing a function as a prop for example.

# ? Feb 21, 2018 08:18

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

prom candy posted:

Would dependency injection have any value here beyond just making this component easier to test? Or is making it easier to test value enough in your opinion?

As others have said, making something easy to test is not a reason in and of it self to change code. It's just that when I *do* have troubles testing something, it frequently (almost entirely) reveals that I should change the code for actual reasons. In his specific case, I don't know if it would have any value, as the code Grump posted is very obviously not his "real" code.

# ? Feb 21, 2018 14:41

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

Sorry for the late reply on this

Lumpy posted:

I'm sure you have but read this first: https://facebook.github.io/jest/docs/en/tutorial-async.html

You can also use nock to mock out requests if you need that.

You can also "replace" imported modules in your test with mocks you write if you want: https://facebook.github.io/jest/docs/en/manual-mocks.html This is probably what you want?

I also find that when something is hard to test, it's because I haven't architected / implemented it as well as it should be. If you make the function a prop you pass in, then you just pass in a jest.mock function and you can verify it's called w/ no API business.

EDIT: Here's a good link I found that may be more helpful then the Jest docs: https://github.com/nilshartmann/jest-playground

EDIT 2: Also, I was under the impression that 'shallow' didn't call any lifecycle methods... are you using enzyme's shallow?

I am using jest-enzyme - sorry should have made that clear.

The issue I�m having is that I�m changing the view based on the response I get back from my API call, so I�m trying to figure out a way to test �my state should be x if the API call returns y.�

Is that possible to do with mock functions?

I can post more of what my component actually looks like when I get in front of a computer

# ? Feb 21, 2018 14:50

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

Grump posted:

Sorry for the late reply on this

I am using jest-enzyme - sorry should have made that clear.

The issue I�m having is that I�m changing the view based on the response I get back from my API call, so I�m trying to figure out a way to test �my state should be x if the API call returns y.�

Is that possible to do with mock functions?

I can post more of what my component actually looks like when I get in front of a computer

I'm not familiar with that testing framework since I am not a React guy, but yes - that's the kind of thing mocking is made for.

# ? Feb 21, 2018 15:00

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

Grump posted:

Sorry for the late reply on this

I am using jest-enzyme - sorry should have made that clear.

The issue I�m having is that I�m changing the view based on the response I get back from my API call, so I�m trying to figure out a way to test �my state should be x if the API call returns y.�

Is that possible to do with mock functions?

I can post more of what my component actually looks like when I get in front of a computer

HaB posted:

I'm not familiar with that testing framework since I am not a React guy, but yes - that's the kind of thing mocking is made for.

Yep. Mock the API call and you can have it return whatever you want, and then check the state after. Reiterating what I and other people have said in the last few posts: use this as a chance to evaluate if things are too tightly coupled as well!

# ? Feb 21, 2018 16:23

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

Thanks guys.

I'm slowly getting the hang of this, but my new issue is that I'm using material-ui and I can't do a mount render without wrapping my component in material-ui's <MuiThemeProvider> component

so basically, my test now looks like this

JavaScript code:

// Setup the module mock. Note that we configure the actual mock behaviour of
// 'loadFromServer' in our individual test cases
jest.mock('../utils/api', () => ({
    verifyOrderId: jest.fn()
}));

it('renders without crashing', () => {
    const component = mount(
        <MuiThemeProvider>
                <MyComponent/>
        </MuiThemeProvider>
    );
    API
        .doTheThing
        .mockImplementation(args);

    expect(API.doTheThing.mock.calls).toHaveLength(1);
    expect(component.find('h1')).toHaveLength(1);
});

but because of this, an error occurs and myComponent doesn't get rendered

teen phone cutie fucked around with this message at 23:20 on Feb 21, 2018

# ? Feb 21, 2018 23:12

huhu: Feb 24, 2006

I believe you should be able to do a named export of your component so that you can import it for testing without having it wrapped with other stuff like the theme provider.

# ? Feb 21, 2018 23:31

reversefungi: Nov 27, 2003; Master of the high hat!

Grump posted:

Thanks guys.

I'm slowly getting the hang of this, but my new issue is that I'm using material-ui and I can't do a mount render without wrapping my component in material-ui's <MuiThemeProvider> component

so basically, my test now looks like this
JavaScript code:
// Setup the module mock. Note that we configure the actual mock behaviour of
// 'loadFromServer' in our individual test cases
jest.mock('../utils/api', () => ({
    verifyOrderId: jest.fn()
}));

it('renders without crashing', () => {
    const component = mount(
        <MuiThemeProvider>
                <MyComponent/>
        </MuiThemeProvider>
    );
    API
        .doTheThing
        .mockImplementation(args);

    expect(API.doTheThing.mock.calls).toHaveLength(1);
    expect(component.find('h1')).toHaveLength(1);
});
but because of this, an error occurs and myComponent doesn't get rendered

Did you look in this discussion? https://github.com/mui-org/material-ui/issues/4664

Seems like you could try a few things, including using "shallow" instead of "mount." Not sure how will that affect the test as I'm only learning enzyme/jest right now myself (as of last week in fact!).

# ? Feb 21, 2018 23:47

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

The Dark Wind posted:

Did you look in this discussion? https://github.com/mui-org/material-ui/issues/4664

Seems like you could try a few things, including using "shallow" instead of "mount." Not sure how will that affect the test as I'm only learning enzyme/jest right now myself (as of last week in fact!).

yeah. it looks like material-ui v1 has testing utils to solve for this, but I can't nothing on v1 is backwards compatible with the version I'm using now.

Can't use a shallow because I need to wait until after componentDidMount is run.

huhu posted:

I believe you should be able to do a named export of your component so that you can import it for testing without having it wrapped with other stuff like the theme provider.

I am doing that, but I keep getting errors that the theme provider is required.

# ? Feb 21, 2018 23:53

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

I know that this is not super helpful but this is one of the ways in which material-ui is a bad library and should never be used.

You need to mock the theme provider, god help you.

# ? Feb 22, 2018 06:36

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

Got around the material-ui issues, but now I need to figure out if there's a way to dive a component deeper with mount?

The response I get back in the test is this

code:

{"length": 1, Symbol(enzyme.__unrendered__): null, Symbol(enzyme.__rendere
r__): {"batchedUpdates": [Function batchedUpdates], "getNode": [Function getNode
], "render": [Function render], "simulateEvent": [Function simulateEvent], "unmo
unt": [Function unmount]}, Symbol(enzyme.__root__): {"length": 1, Symbol(enzyme.
__unrendered__): <MyComponent />, Symbol(enzyme.__renderer__): [Object], Symbol(
enzyme.__root__): [Circular], Symbol(enzyme.__node__): [Object], Symbol(enzyme._
_nodes__): [Array], Symbol(enzyme.__options__): [Object]}, Symbol(enzyme.__node_
_): {"instance": [Object], "key": undefined, "nodeType": "class", "props": [Obje
ct], "ref": null, "rendered": [Object], "type": [Function VerifyModal]}, Symbol(
enzyme.__nodes__): [[Object]], Symbol(enzyme.__options__): {"adapter": [Object],
 "childContextTypes": [Object], "context": [Object]}}

So this is the material-ui theme provider wrapper, but now I need to somehow get a component deeper. I know shallow has a dive() function, but it doesn't seem like mount has anything like that.

teen phone cutie fucked around with this message at 20:43 on Feb 22, 2018

# ? Feb 22, 2018 19:30

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

Grump posted:

Got around the material-ui issues, but now I need to figure out if there's a way to dive a component deeper with mount?

The response I get back in the test is this

code:

{"length": 1, Symbol(enzyme.__unrendered__): null, Symbol(enzyme.__rendere
r__): {"batchedUpdates": [Function batchedUpdates], "getNode": [Function getNode
], "render": [Function render], "simulateEvent": [Function simulateEvent], "unmo
unt": [Function unmount]}, Symbol(enzyme.__root__): {"length": 1, Symbol(enzyme.
__unrendered__): <MyComponent />, Symbol(enzyme.__renderer__): [Object], Symbol(
enzyme.__root__): [Circular], Symbol(enzyme.__node__): [Object], Symbol(enzyme._
_nodes__): [Array], Symbol(enzyme.__options__): [Object]}, Symbol(enzyme.__node_
_): {"instance": [Object], "key": undefined, "nodeType": "class", "props": [Obje
ct], "ref": null, "rendered": [Object], "type": [Function VerifyModal]}, Symbol(
enzyme.__nodes__): [[Object]], Symbol(enzyme.__options__): {"adapter": [Object],
 "childContextTypes": [Object], "context": [Object]}}

So this is the material-ui theme provider wrapper, but now I need to somehow get a component deeper. I know shallow has a dive() function, but it doesn't seem like mount has anything like that.

What are you actually drying to do / test?

Also, material-ui sounds awful, I'm sorry :smith:

# ? Feb 22, 2018 21:18

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

Lumpy posted:

What are you actually drying to do / test?

Also, material-ui sounds awful, I'm sorry

I have two fetch requests that are running in my componentDidMount. Based on the response I get from my API call, I am rendering a view.

So I want to test "if response is x, view y should be showing"

but material-ui is making it impossible, and after submitting a Github issue, the response I got back from the developer was

quote:

Sorry, I have only experience writing tests for Material-UI in userland and enzyme with v1.

This is so stupid. Writing code is stupid and I hate it

# ? Feb 22, 2018 22:09

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

Grump posted:

I have two fetch requests that are running in my componentDidMount. Based on the response I get from my API call, I am rendering a view.

So I want to test "if response is x, view y should be showing"

but material-ui is making it impossible, and after submitting a Github issue, the response I got back from the developer was

This is so stupid. Writing code is stupid and I hate it

Because I'm stupid, explain why you need to wrap your stuff in this 'theme provider' thing?

Also, have you considered abstracting this stuff out a bit? Again, don't do this only because it makes testing easier, but what you are doing seems a little off. Are you using any sort of state management (Redux / Mobx, etc.) ?

You really want to test "did my network requests set state X for response A" type things, and then also "if my state is X, am I rendering component Z", correct? What if you did something like creating a simple component that took two component props and a bool that just rendered one or the other:

code:

// please note this is pseudo-code!
const Switcher = (A, B, useA) => ( useA ? A : B);

Then your current class-based component takes two props for those "view" components and renders the Switcher when your requests are done. Your tests are now easy because you pass in <p>View Y</p> and <p>View Z</p> in your tests, so there's no material-ui involved at all, and you have an easily testable, reusable, Switcher component for the same reasons, and your "real" view components can be tested in isolation.

This may be a terrible solution because I don't know your use-case, but at least is an example of how abstracting things can make testing easier while also giving your reusable generic components.

# ? Feb 22, 2018 22:46

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 12:30

Capri Sun Tzu: Oct 24, 2017; by Reene

Grump posted:

I have two fetch requests that are running in my componentDidMount. Based on the response I get from my API call, I am rendering a view.

So I want to test "if response is x, view y should be showing"

but material-ui is making it impossible, and after submitting a Github issue, the response I got back from the developer was

This is so stupid. Writing code is stupid and I hate it

The Cavern of COBOL > Modern front-end development: Writing code is stupid and I hate it

# ? Feb 22, 2018 22:49

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

«‹›235 »