Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
teen phone cutie
Jun 18, 2012

last year i rewrote something awful from scratch because i hate myself

Lumpy posted:

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:

This is what I'm doing in my JSX. But the API calls are happening in the most parent-level component, so that's what I need to test. My componentDidMount and render methods of the most parent-level component is something like:

JavaScript code:
// not actual code
state: {
	formView: "loading-view"
}
componentDidMount(){
	API.doTheThing(),then(data => {
		if(data.message === 'DOB'){
			this.setState({formView: "dob-form"})
		}
		else{
			this.setState({formView: "welcome-message"})
		}
	}
}
JavaScript code:
// not actual code
render(){
	return(
 	if(this.state.formView === 'dob-form'){
			<DobForm/>
		}
		else{
			<Welcome/>
		}
	)
}
The reason I need the theme provider is just because material-ui requires it to be there. Trust me, I've been googling answers for hours - I don't think there's any way around it.

e: I suppose I could make another component to render my now most parent-level component, but that would be extremely dumb and unnecessary

teen phone cutie fucked around with this message at 23:05 on Feb 22, 2018

Adbot
ADBOT LOVES YOU

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

Capri Sun Tzu posted:

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

The thread title hasn't changed in a while...

EVIL Gibson
Mar 23, 2001

Internet of Things is just someone else's computer that people can't help attaching cameras and door locks to!
:vapes:
Switchblade Switcharoo
Worked on deploying on a Ruby on Rails app at work and it was fun stuff working with ActiveRecord and how it can seamlessly make those connections through tables without writing complex queries (as long as you are super good writing out the relationships).

We pushed it out today and looking over the code that imports the data from JIRA through it's API, I feel like I didn't abuse ActiveRecords as much. mainly knowing how to easily find out if they exist in unfamiliar tables quickly in 'rails c'

If the relation exists between, let's say 'ingredients' and 'recipes' and 'prices' and we say a recipes can have many ingredients, 1 ingredient has 1 price, how can I find out from inside the console without, going out to the migration files, see if the ActiveRecord will allow me to do something like Recipes.where(recipe_name: "PORK AND BEANS").price.total is possible.

Example of something I was impressed/horrified was the autocomplete on '.' that would list all methods that datatype allows you to do.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

While writing code often is stupid, in this instance (and it is of course common) using libraries is what is stupid!

It's really hard to write a nice API for a library. I certainly can't do it well. So of course most libraries suck to use.

In fact, I'd say that the vast majority of the time I'm thinking that coding is stupid its because I'm trying to glue together libraries or something. I'm much more zen when I'm just writing vanilla code...but of course you can't do anything in reasonable amounts of time if you just do that.

prom candy
Dec 16, 2005

Only I may dance
Does your component reference material ui at all? If not can you mock the two child components so that you can still use mount and get your lifecycle methods but not actually render the components that rely on mui? You just need to test that the right thing is rendered, right? Alternately I think the stupid theme provider or whatever just uses context, can you pass arbitrary context in with enzyme?

Also I am finding a lot of people in the React community are pushing integration tests since it's pretty easy to write an app where all your unit tests are green but your poo poo is still broken. You could consider going the other direction and rendering your whole app with whatever set of props you need to render this particular component.

Testing is a huge pain in the rear end but so is breaking the build.

Tei
Feb 19, 2011

Capri Sun Tzu posted:

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

I love it. I have programmed a canon to shoot nerf darts at me when I am not smiling while programming. I am smiling just now, these darts hurt.

Nolgthorn
Jan 30, 2001

The pendulum of the mind alternates between sense and nonsense

Thermopyle posted:

While writing code often is stupid, in this instance (and it is of course common) using libraries is what is stupid!

It's really hard to write a nice API for a library. I certainly can't do it well. So of course most libraries suck to use.

In fact, I'd say that the vast majority of the time I'm thinking that coding is stupid its because I'm trying to glue together libraries or something. I'm much more zen when I'm just writing vanilla code...but of course you can't do anything in reasonable amounts of time if you just do that.

Part of the issue is that too many libraries try to do too many things, and themselves use too many libraries as well. Which seems to be acceptable which is also an issue. The current standard stack seems to be Webpack, Babel, React/Redux. Which is nuts.

Nolgthorn
Jan 30, 2001

The pendulum of the mind alternates between sense and nonsense
I'm trying to get serious about switching away from `npmjs` as it's something I've been wanting to do for a while. The recent bug that has been wiping out servers and the dev's response has finally pushed me to devote some time to it.

As I understand use of the npm repository is inescapable for general work. But maybe I can get away from their cli, something like yarn although I'd like to also avoid it, yarn has a lot of the same foundational issues with team structure and politics that npm suffers from.

Anyone have experience with other ones?

ynohtna
Feb 16, 2007

backwoods compatible
Illegal Hen
I've been happily using jspm for personal projects over the last few years. It's super flexible and configurable, supports multiple package sources & formats, transpiles modern JS out of the box, hot reloads etc, and is easily extended (I knocked up an eslisp loader in an afternoon (cos I'm a masochist)).

I always get weird recoiling reactions when I mention it to other coders who're over-attached to their weeks of Webpack config hacking, though, so maybe it's made of haram farts.

Nolgthorn
Jan 30, 2001

The pendulum of the mind alternates between sense and nonsense
Jspm looks neat. I've also never heard of Traceur I've been using Bubel for es6->es5 compilation I could try out both of those tools. What gives me pause is the really long page about publishing, it seems not to be focused or maybe it's just really detailed.

Could you give me a brief example of how you would publish a module?

ynohtna
Feb 16, 2007

backwoods compatible
Illegal Hen
Ah, I've never published a module.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Grump posted:

This is what I'm doing in my JSX. But the API calls are happening in the most parent-level component, so that's what I need to test. My componentDidMount and render methods of the most parent-level component is something like:

code:
...
The reason I need the theme provider is just because material-ui requires it to be there. Trust me, I've been googling answers for hours - I don't think there's any way around it.

e: I suppose I could make another component to render my now most parent-level component, but that would be extremely dumb and unnecessary

I probably explained badly what I meant in my post.

So now, with your code, you are probably rendering your parent-level component like so:

code:
<ParentLevel />
What I was getting at was do it like this:

code:
<ParentLevel viewA={ DobForm } viewB={ Welcome }  />
And make that "render one of two view based on a bool" Switcher component. Then your render method becomes:
JavaScript code:
render() {
  const { viewA, viewB } = this.props;
   const { formView } = this.state;
    if( formView === 'loading' ) {
      return <LoadingView />
    }
    return ( <Switcher 
      useA={ formView === 'dob-form' }
      viewA={ viewA }
      viewB={ viewB }
    /> )
}
Then in your tests, you do this:
code:
const TestA = <p>A</p>
const TestB = <p>B</p>

// inside test method....
<ParentLevel viewA={ TestA } viewB={ TestB }  />
Now you aren't looking at material-ui wrapped views in your tests. If ParentLevel needs to be wrapped in material-ui, then... uhhh. :smith:

But seeing more detail here, it looks like you are building a router...

EDIT: I assume you have tried using the functions that material ui exposes to test with rather than enzyme's default ones? https://material-ui-next.com/guides/testing/#userspace

Lumpy fucked around with this message at 16:42 on Feb 23, 2018

Chenghiz
Feb 14, 2007

WHITE WHALE
HOLY GRAIL

Nolgthorn posted:

yarn has a lot of the same foundational issues with team structure and politics that npm suffers from.

Can you be more specific here?

Nolgthorn
Jan 30, 2001

The pendulum of the mind alternates between sense and nonsense
No because I don't want to get into a political argument I only want good tools so that I can make stuff, politics belong nowhere near software. Politics are what npm and yarn are suffering from so I'll look for software developers who are interested in software.

dupersaurus
Aug 1, 2012

Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'
Isn't political quagmire the natural and inherent state of an open-source project?

Nolgthorn
Jan 30, 2001

The pendulum of the mind alternates between sense and nonsense
I hope to find out

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

Nolgthorn posted:

politics belong nowhere near software.

This is peak nerd.

Politics are part of everything.

edit: well part of everything that has more than a person or two working on it.

Thermopyle fucked around with this message at 20:25 on Feb 23, 2018

huhu
Feb 24, 2006
Nolgthorn have you ever worked on a team before?

teen phone cutie
Jun 18, 2012

last year i rewrote something awful from scratch because i hate myself

Thanks for the help. I got it working. (my parent level HAD to be wrapped in material-ui. The docs you posted are for v1, but I'm using v0, so they don't apply to my situation, since v1 is completely not backwards compatible with v0, unfortunately)

Here's what my test looks like. I just console logged component.debug() to see what the html output was and it turned out I was just targeting the wrong selector in find(). Also, it turns out enzyme’s shallow does call lifecycle methods

That being said, never using material-ui ever again.

JavaScript code:
// Syntactic sugar, see:
// [url]https://github.com/facebook/jest/issues/2157#issuecomment-279171856[/url] something
// like this will maybe added to the Jest API
function flushPromises() {
    return new Promise(resolve => setImmediate(resolve));
}

// required for material-ui components
const muiTheme = getMuiTheme();

it('renders the upload form if failed-waiting-for-upload is returned from fetch requ' +
        'est',
() => { 
    // mock response of our first fetch request in componentDidMount
    fetch
        .__orig__
        .mockResponseOnce(JSON.stringify({
            meta: {
                status: "success"
            },
            data: {
                configuration: {
                    ssnFieldLabel: "Last 4 Digits of SSN (Optional)",
                    dobFieldLabel: "Please enter your date of birth"
                }
            }
        }));

    // mock response of our second fetch request in componentDidMount
    fetch
        .__orig__
        .mockResponseOnce(JSON.stringify({
            meta: {
                status: "error"
            },
            data: {
                verification: {
                    verified: false,
                    state: "failed-waiting-for-upload",
                    already_attempted: true
                }
            }
        }));

    const component = shallow(
        <VerifyModal/>, {
        context: {
            muiTheme // needed for material-ui
        },
        childContextTypes: {
            muiTheme: PropTypes.object
        }
    });

    return flushPromises().then(() => {
        // componentDidMount has run at this point
        //
        // setState has run at this point
        expect(fetch.__orig__.mock.calls).toHaveLength(2);
        component.update(); // re-render the component
        expect(component.find('UploadForm')).toHaveLength(1); // upload form should render
    });
});
But now I have questions about testing best practices. In the test above, I'm checking what the HTML output is based off what data gets returned from my fetch request

So the flow goes like this:

componentDidMount -> fetch request happens -> set state based on response -> render the appropriate view

My questions is this: Should I be testing views based on a response from an API or should I just base it from what the state is? Or should I do both? My fear is that I'm testing async stuff for no real reason. To be honest, this is my first experience writing tests ever, so I'm not really sure what I should and shouldn't be testing.

teen phone cutie fucked around with this message at 00:29 on Feb 24, 2018

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
Well I assume that the API calls mutates your state and then the state determines the HTML right? So I would probably recommend testing that the API calls are correctly mutating the state. Then have a separate test that the state is being rendered correctly.

teen phone cutie
Jun 18, 2012

last year i rewrote something awful from scratch because i hate myself

a hot gujju bhabhi posted:

Well I assume that the API calls mutates your state and then the state determines the HTML right? So I would probably recommend testing that the API calls are correctly mutating the state. Then have a separate test that the state is being rendered correctly.

Yeah that’s probably a good idea. Thanks!

Also, I don’t really understand if these tests are actually making a real fetch request or just mocking the actual request as well. What’s the easiest way to check this without looking at the server logs?

Master Stur
Jun 13, 2008

chasin' tail

Nolgthorn posted:

I'm trying to get serious about switching away from `npmjs` as it's something I've been wanting to do for a while. The recent bug that has been wiping out servers and the dev's response has finally pushed me to devote some time to it.

As I understand use of the npm repository is inescapable for general work. But maybe I can get away from their cli, something like yarn although I'd like to also avoid it, yarn has a lot of the same foundational issues with team structure and politics that npm suffers from.

Anyone have experience with other ones?

Yarn actually has good engineering decisions behind it though. NPM is a mess in many areas from childish contributor behavior to a really poorly done backend and completely bungling 5.0+. I don't think team politics is to blame for this. As you said, you want software, but if you want wide support you should give yarn a chance.

Chenghiz
Feb 14, 2007

WHITE WHALE
HOLY GRAIL
Yeah, we've been using yarn for a while (maybe a year now? I can't remember) and it's been way more reliable than npm. I was kinda wondering if there was some governance issue I wasn't aware of, but I guess not. I try to keep up on those things.

fletcher
Jun 27, 2003

ken park is my favorite movie

Cybernetic Crumb
I have a vuejs project I'm building for a Chrome Extension. How can I output my manifest.json for the extension as part of the "vue-cli-service build" process?

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

Grump posted:

Yeah that’s probably a good idea. Thanks!

Also, I don’t really understand if these tests are actually making a real fetch request or just mocking the actual request as well. What’s the easiest way to check this without looking at the server logs?

Well your mock should hopefully contain mock data that just matches the "shape" of real data. So you should be able to tell by the contents of the "response" whether it is a mock response or a real one. This depends a little bit on the specific scenario though, so it's a tricky question to answer definitively.

fletcher
Jun 27, 2003

ken park is my favorite movie

Cybernetic Crumb

fletcher posted:

I have a vuejs project I'm building for a Chrome Extension. How can I output my manifest.json for the extension as part of the "vue-cli-service build" process?

Found what I was looking for in these docs: https://github.com/vuejs/vue-cli/tree/dev/docs

Nolgthorn
Jan 30, 2001

The pendulum of the mind alternates between sense and nonsense
https://developer.mozilla.org/en-US/docs/Web/API/Push_API

I'd like to get push notifications working, is the only way to do it with a Google API key? There has got to be another way to do it. Related, I see a load of website push notification startups out there but I can't figure out what they're doing that I can't do with a small amount of code myself. It seems like I just send a POST request to their endpoint instead of the Google API endpoint mentioned.

And either way I still need a Google API key.

Nolgthorn fucked around with this message at 07:29 on Feb 26, 2018

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice
So here's a stupid question: Snapshot testing. If my code is dumb on the first run, I made a bad snapshot, and now it's bad forever, since I'll be comparing to a bugged snapshot. So is best practice to hard-code the output for that first run? If so, why does no tutorial / docs anything mention that? If not, what stupid thing am I missing?

huhu
Feb 24, 2006

Lumpy posted:

So here's a stupid question: Snapshot testing. If my code is dumb on the first run, I made a bad snapshot, and now it's bad forever, since I'll be comparing to a bugged snapshot. So is best practice to hard-code the output for that first run? If so, why does no tutorial / docs anything mention that? If not, what stupid thing am I missing?

From what I gathered, you need to check the snapshot when you first create it. I'm not too fond of that though. My personal opinion is that most of the time snapshots are the lazy way to write tests and they can be done better.

smackfu
Jun 7, 2004

Chenghiz posted:

Yeah, we've been using yarn for a while (maybe a year now? I can't remember) and it's been way more reliable than npm.

Just curious, how was npm unreliable for you? We really haven’t seen any reliability issues on our team.

IAmKale
Jun 7, 2007

やらないか

Fun Shoe

smackfu posted:

Just curious, how was npm unreliable for you? We really haven’t seen any reliability issues on our team.
How about a bug that annihilates file permissions across the file system because an RC was tagged as a @next release? https://github.com/npm/npm/issues/19883

Not that I particularly support those idiots installing @next releases on production...

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

IAmKale posted:

How about a bug that annihilates file permissions across the file system because an RC was tagged as a @next release? https://github.com/npm/npm/issues/19883

Not that I particularly support those idiots installing @next releases on production...

Yarn is just a thing that sits on top of npm though, right? So you can still have that npm bug using Yarn if yarn installs that npm as part of *it's* install??

Nolgthorn
Jan 30, 2001

The pendulum of the mind alternates between sense and nonsense
I have discovered and am excited about pnpm.

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe

Lumpy posted:

Yarn is just a thing that sits on top of npm though, right? So you can still have that npm bug using Yarn if yarn installs that npm as part of *it's* install??

npm is two parts: a website full of tar files, and a client that downloads and extracts the tar files.

yarn replaces the second thing without replacing the first thing. so no, yarn will not have that bug.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Suspicious Dish posted:

npm is two parts: a website full of tar files, and a client that downloads and extracts the tar files.

yarn replaces the second thing without replacing the first thing. so no, yarn will not have that bug.

Ah, okay. For some reason I thought it still called the npm client under the hood. Thanks for the info!

Sedro
Dec 31, 2008

smackfu posted:

Just curious, how was npm unreliable for you? We really haven’t seen any reliability issues on our team.

npm is unreliable by design if you don't use a lockfile and npm shrinkwrap was broken for as long as I used npm. yarn came along with working lockfiles and much better performance to boot. npm might be better now but there's no incentive for me to switch back.

Nolgthorn
Jan 30, 2001

The pendulum of the mind alternates between sense and nonsense

Sedro posted:

might be better now but there's no incentive for me to switch back.

Fewer dependencies and libraries. Otherwise, I want there to be more better reasons than that.

Chenghiz
Feb 14, 2007

WHITE WHALE
HOLY GRAIL

smackfu posted:

Just curious, how was npm unreliable for you? We really haven’t seen any reliability issues on our team.

We had issues with different versions of dependencies getting installed in CI than in development, primarily. This was before npm lockfiles and we weren't using shrinkwrap because I didn't like it as a solution (don't remember why, now).

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

Nolgthorn posted:

I have discovered and am excited about pnpm.

Next week I think they're releasing npnpm, which will be one whole letter better.

Adbot
ADBOT LOVES YOU

Maluco Marinero
Jan 18, 2001

Damn that's a
fine elephant.
The nail in the coffin for npm for me was when it ran out of memory doing ‘npm install’ on 1GB instances I was trying to provision, absolutely no way around it, the process would die every time. Yarn, of course, handled the install just fine and way faster.

The idea that a package manager needs more than 1GB of ram just to execute is pretty comical to me.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply