|
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:
JavaScript code:
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 |
# ? Feb 22, 2018 22:58 |
|
|
# ? May 27, 2024 13:17 |
|
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...
|
# ? Feb 23, 2018 01:26 |
|
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.
|
# ? Feb 23, 2018 02:02 |
|
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.
|
# ? Feb 23, 2018 04:32 |
|
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.
|
# ? Feb 23, 2018 06:02 |
|
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.
|
# ? Feb 23, 2018 11:08 |
|
Thermopyle posted:While writing code often is stupid, in this instance (and it is of course common) using libraries is what is stupid! 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.
|
# ? Feb 23, 2018 12:55 |
|
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?
|
# ? Feb 23, 2018 14:08 |
|
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.
|
# ? Feb 23, 2018 14:28 |
|
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?
|
# ? Feb 23, 2018 14:53 |
|
Ah, I've never published a module.
|
# ? Feb 23, 2018 15:11 |
|
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: 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:
code:
JavaScript code:
code:
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 |
# ? Feb 23, 2018 16:29 |
|
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?
|
# ? Feb 23, 2018 18:28 |
|
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.
|
# ? Feb 23, 2018 19:03 |
|
Isn't political quagmire the natural and inherent state of an open-source project?
|
# ? Feb 23, 2018 19:19 |
|
I hope to find out
|
# ? Feb 23, 2018 19:20 |
|
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 |
# ? Feb 23, 2018 20:18 |
|
Nolgthorn have you ever worked on a team before?
|
# ? Feb 23, 2018 20:53 |
|
Lumpy posted:words 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:
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 |
# ? Feb 23, 2018 23:34 |
|
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.
|
# ? Feb 24, 2018 00:38 |
|
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?
|
# ? Feb 24, 2018 01:38 |
|
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. 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.
|
# ? Feb 24, 2018 02:31 |
|
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.
|
# ? Feb 24, 2018 17:41 |
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?
|
|
# ? Feb 25, 2018 22:23 |
|
Grump posted:Yeah that’s probably a good idea. Thanks! 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.
|
# ? Feb 26, 2018 02:22 |
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
|
|
# ? Feb 26, 2018 05:40 |
|
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 |
# ? Feb 26, 2018 07:22 |
|
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?
|
# ? Feb 26, 2018 17:16 |
|
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.
|
# ? Feb 26, 2018 18:45 |
|
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.
|
# ? Feb 27, 2018 14:00 |
|
smackfu posted:Just curious, how was npm unreliable for you? We really haven’t seen any reliability issues on our team. Not that I particularly support those idiots installing @next releases on production...
|
# ? Feb 27, 2018 17:06 |
|
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 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??
|
# ? Feb 27, 2018 18:00 |
|
I have discovered and am excited about pnpm.
|
# ? Feb 27, 2018 18:31 |
|
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.
|
# ? Feb 27, 2018 18:44 |
|
Suspicious Dish posted:npm is two parts: a website full of tar files, and a client that downloads and extracts the tar files. Ah, okay. For some reason I thought it still called the npm client under the hood. Thanks for the info!
|
# ? Feb 27, 2018 18:54 |
|
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.
|
# ? Feb 27, 2018 20:33 |
|
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.
|
# ? Feb 28, 2018 01:14 |
|
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).
|
# ? Feb 28, 2018 03:52 |
|
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.
|
# ? Feb 28, 2018 05:22 |
|
|
# ? May 27, 2024 13:17 |
|
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.
|
# ? Feb 28, 2018 05:33 |