|
Lumpy posted:GraphQL / Apollo question! Is there a way to take the Date(s) I get from my query that are ISO 8601 strings and have them converted to js Date objects magically? Obviously running a map on the return gets the job done, but You can do it in the return function(s) for the column(s).
|
# ? Apr 24, 2019 18:07 |
|
|
# ? Jun 3, 2024 17:06 |
|
prom candy posted:Yeah, not worth it just to use arrow functions in this case imo This pattern is pretty common if you switch to using hooks instead of classes just fyi, since you need to set your function to a variable so you can attach .defaultProps and .propTypes to it before exporting it. code:
|
# ? Apr 24, 2019 18:12 |
|
HaB posted:You can do it in the return function(s) for the column(s). Care to explain / point me at docs? I am both stupid and bad at google.
|
# ? Apr 24, 2019 18:22 |
|
Lumpy posted:Care to explain / point me at docs? I am both stupid and bad at google. Resolver is the term I was looking for. In the resolver for the column. Also, you can create Date as a type, at least you can in the javascript graphql lib. Here's how I did it: code:
|
# ? Apr 24, 2019 18:53 |
|
prom candy posted:If there are no types for a third party library I just declare the fucker and move on with my life. Maybe it makes me a bad developer but I'm not afraid to just fall back on any if I feel like I'm wasting time trying to please the type gods. I really should do this more often. I spent most of last Friday fighting with typescript and trying to get the complementary @types/* library to actually work right so that I could import and type some methods for this library. I ended up not using @types/*, and just writing my own that didn't have obscure errors. I think that the official poo poo was referencing requirejs which caused "require" to be declared twice and breaking the build. Typed languages are good, but TypeScript seems to just waste my time and the sooner we can get better types into the spec., the better.
|
# ? Apr 24, 2019 20:11 |
|
ddiddles posted:This pattern is pretty common if you switch to using hooks instead of classes just fyi, since you need to set your function to a variable so you can attach .defaultProps and .propTypes to it before exporting it. I've already switched to hooks but I rarely use default props and I never use prop types because of TypeScript
|
# ? Apr 24, 2019 20:52 |
|
spacebard posted:I really should do this more often. I spent most of last Friday fighting with typescript and trying to get the complementary @types/* library to actually work right so that I could import and type some methods for this library. I ended up not using @types/*, and just writing my own that didn't have obscure errors. I think you want https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm Some goon even made an Elm-alike in Rust
|
# ? Apr 24, 2019 21:31 |
|
prom candy posted:I've already switched to hooks but I rarely use default props and I never use prop types because of TypeScript Fair enough, I usually only do them for passed in functions that can be optional, so you're code can just call it and not worry about it, or if I'm just lazy as hell and I dont want to do null checks. Been resisting Typescript for so long, but messing around with C# has made me want to try it out.
|
# ? Apr 24, 2019 21:44 |
|
Default props get kinda weird with TypeScript because they're nullable but if there's a default prop you know it's not null. I basically stopped using them because it's annoying. I might just be dumb though and someone has a great solution. TypeScript overall is really great, I love getting compile time errors instead of runtime errors
|
# ? Apr 24, 2019 22:39 |
|
Thermopyle posted:I mean, I know its worth it. I like types, but geeze it took me hours working in a single 30 line file trying to get the types for various third party libraries working right. Munkeymon posted:I think you want https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm Dominoes fucked around with this message at 22:48 on Apr 24, 2019 |
# ? Apr 24, 2019 22:45 |
|
HaB posted:Resolver is the term I was looking for. In the resolver for the column. Also, you can create Date as a type, at least you can in the javascript graphql lib.
|
# ? Apr 24, 2019 22:57 |
|
Lumpy posted:This can happen on the client? I know about resolvers on the server side, but I was hoping there was something on the client I could do like that. Oh sorry, I misunderstood. I can’t think of a boilerplate solution other than just massaging the data as it comes back.
|
# ? Apr 25, 2019 01:14 |
|
What do y'all use for unit testing frontend components in the SPA of your choice? We use Vue but I'd be interested in experiences with other frameworks as well. Currently we're using Karma+Jasmine for some reason obscured by the mists of time - it's absolutely dog slow (although mainly because of webpack rebuilds), test failures (and especially syntax errors and other exceptions) produce almost incomprehensible error messages and everyone hates it in general. I used tap a few years ago in a node project and as far as I can recall that was pretty nice, but I'm really not much of a frontend guy so I dunno what people find needs suiting for testing SPA's.
|
# ? Apr 25, 2019 14:51 |
|
Anybody here carrying the torch for "Data Visualization" as a job title? I'm in NYC and had luck finding good positions, but I wonder if moving to SF is inevitable (provided DV can stay separate from Data Science at all). More generally, do you work in a specialized programming job and find it going well / ok / terrible? It's a topic I'd love to hear more about.
|
# ? Apr 25, 2019 15:03 |
|
Dominoes posted:I usually end up 'any'ing those. TS's type system breaks down with many 3rd-party libs, and is awkward to use for DOM types. Yeah, thats probably the right thing to do, but I have this irrational aversion to `any`.
|
# ? Apr 25, 2019 15:52 |
|
TheFluff posted:What do y'all use for unit testing frontend components in the SPA of your choice? We use Vue but I'd be interested in experiences with other frameworks as well. Currently we're using Karma+Jasmine for some reason obscured by the mists of time - it's absolutely dog slow (although mainly because of webpack rebuilds), test failures (and especially syntax errors and other exceptions) produce almost incomprehensible error messages and everyone hates it in general. I used tap a few years ago in a node project and as far as I can recall that was pretty nice, but I'm really not much of a frontend guy so I dunno what people find needs suiting for testing SPA's. We also use Vue + karma but are taking a look at jest because that seems to be where the community is headed.
|
# ? Apr 25, 2019 19:37 |
|
Does anyone do pure integration testing? I checked out cyrpressjs and I'm not really sure the use case for unit testing anymore.
|
# ? Apr 25, 2019 22:00 |
|
We did Browstack for a while, but now it's just a steaming shitpile of randomly failing VMs. Looking for alternative solution, as we have a ton of TestCafe tests nobody wants to rewrite. E: we'll probably just do headless homegrown in the meantime.
|
# ? Apr 25, 2019 22:14 |
|
I don't really unit test React components, I don't feel like it's all that valuable. I just hit myself with a brutal self-own that cost me most of an afternoon. I've been doing a big refactor of part of our app and part of that has been converting this top-level component from a class component to a function component and using hooks. Further down the chain I had a component with a pretty aggressive shouldComponentUpdate method. I started running into weird behaviour where it seemed like my functions in my top-level component that were being called by events in my lower component were referencing previous state values. Well guess what, they loving were because when you switch from a class component to a function component the functions that are defined in your render method literally have the state values baked into them, so when you pass them as props if you don't let the child component re-render then it's just going to keep calling the same old version of the function and be very confusing during a refactor. I thought that my whole understanding of how function components and hooks worked was mistaken, turns out I'm just dumb and didn't remember something a lot more basic. Whoops.
|
# ? Apr 25, 2019 22:41 |
|
I don't really feel it either. What I'd really like test coverage for is state management poo poo, but that's not quite unit testing and I haven't really figured out a good way to test it yet either.
|
# ? Apr 25, 2019 23:13 |
|
ddiddles posted:Does anyone do pure integration testing? I checked out cyrpressjs and I'm not really sure the use case for unit testing anymore. By "pure integration testing" do you mean "integration testing and nothing else"? Cypress is about as good for what it does as I think it can reasonably hope to be, but I've found that Cypress tests are frustrating to write, brittle to maintain and slow to run. So we keep that kind of testing to an absolute minimum and "shift left" as far as possible. All our lower-level tests use Jest. I dislike unit testing React components so I try to factor the complex logic out to individual testable functions where possible.
|
# ? Apr 25, 2019 23:16 |
|
Doom Mathematic posted:By "pure integration testing" do you mean "integration testing and nothing else"? Cypress is about as good for what it does as I think it can reasonably hope to be, but I've found that Cypress tests are frustrating to write, brittle to maintain and slow to run. So we keep that kind of testing to an absolute minimum and "shift left" as far as possible. All our lower-level tests use Jest. Ah, yeah the test length is a good point, just been playing around with it with a few small flows but I could see it being pretty length in a full coverage app. I was just dreaming of a world where I could dump all my testing responsibilities onto QA
|
# ? Apr 26, 2019 00:56 |
|
Analytic Engine posted:Anybody here carrying the torch for "Data Visualization" as a job title? I'm in NYC and had luck finding good positions, but I wonder if moving to SF is inevitable (provided DV can stay separate from Data Science at all). I don't officially have data visualization as part of my title, but I've been working on making it a bigger and more important part of my role/skill set at my current job (by specifying more sophisticated visualizations for our product and getting really good at D3. Since I come from a design background rather than a computer science/programming one, I want to have a less-common specialization that leverages my design background to compensate for the holes in my education and experience. Helps that I very much enjoy doing data visualization. I would like to learn more about data analysis, big data, and related math and stuff, but my main focus is on the UI side of things. As for moving to SF, I would hope it's not inevitable. I grew up in the Bay Area and you couldn't pay me enough to move back there at this point. Good thing is that not all sectors where you'd find demand for data visualization (finance, healthcare) are centered in SF.
|
# ? Apr 26, 2019 02:54 |
|
Doom Mathematic posted:I dislike unit testing React components so I try to factor the complex logic out to individual testable functions where possible. I think this is the correct thing to do. The only React components that need testing are the ones that have logic going on in them, and, anyway, you should be shoving stuff into easily-testable functions no matter which framework you're using....so you really don't have a lot of need to test React components themselves. (not that I always do this, but it's the ideal thing to do)
|
# ? Apr 26, 2019 16:21 |
|
I've been using react-testing-libarary because i like how its set up for you to test the functionality rather than the implementation, what with getting inputs by their text value, simulating actual events, etc, with the bonus points being it handles hooks out of the box an all async stuff that was always a pain in the rear end with enzyme just seemed to go away. Admittedly I think i was doing enzyme testing completely wrong before I switched. I know enzyme also has that functionality but all their docs when I was first starting out were things like checking status variables and props. And then I wrote a 40 line cypressjs test that successfully tests the happy path on a multi page login in form in five different viewports and I wanted the rest of my life to be like that
|
# ? Apr 26, 2019 17:09 |
|
The cypress examples all seem to use public APIs. How do people use it for running local tests? Is there a built in way to start/stop a local server instance?
|
# ? Apr 27, 2019 14:15 |
|
You can listen to http requests based on url and intercept them. https://docs.cypress.io/api/commands/route.html#Syntax
|
# ? Apr 27, 2019 20:03 |
|
smackfu posted:The cypress examples all seem to use public APIs. How do people use it for running local tests? Is there a built in way to start/stop a local server instance? No, starting the server instance is not Cypress' responsibility, you have to start it yourself before the Cypress test begins and then point Cypress at it using config/command line options. For local development, I/we have a local webpack dev server running continually, and Cypress can be pointed at that. The same tests can equally well be run against a real server. E: you can stub out individual HTTP responses as ddiddles suggests, which is useful if you're only testing the way the front-end behaves in itself, and/or you want to force various error conditions. We try to keep this to a minimum though, because one of our objectives with Cypress testing is to be able to test what happens when the real front-end gets real responses from the real server. Doom Mathematic fucked around with this message at 20:22 on Apr 27, 2019 |
# ? Apr 27, 2019 20:17 |
|
For sure, you shouldn't stub out any api requests that you don't have to pay for, and maybe even then it might be worth it to pay the cost of some extra calls to your real third party APIs and not even bother with it.
|
# ? Apr 27, 2019 20:29 |
|
Doubleposting cause I should have been sleeping hours ago. I'm pretty impressed with how easy it is to use googles cloud offerings, specifically their vision api. I set up a quick flow where a front end uploads an images of handwriting or a picture of a document to a storage bucket, and a cloud function picks up on that and runs the image through the vision API, then pushes the results to a firestore db. This was in about 40-50 lines of client library code and a file input. Happens really quickly as well, 1-2 seconds round trip for the data to show up in db. huge recording of it if anyones interested in the speed https://i.imgur.com/OJWACLV.gifv (no idea why [url] was inlining it ) also lol at one of my file names
|
# ? Apr 30, 2019 07:47 |
|
I've been testing this site I'm working on, on different OS and browsers using browserstack. On Windows, both IE and Chrome makes the scrollbar overlap the page, effectively hiding part of it. Is this a normal Windows-thing I have to account for somehow, or have I goofed up? Edit: It seems to be affecting the header, mainly. I've tried to make elements of the header always be visible, regardless of the viewport size and the width of the body. I've done this by adding "width: calc(100vw - 40px)" to the header div (20px is the padding), to ensure it always resizes to the width of the viewport. Is there a better way to achieve what I want? uncle blog fucked around with this message at 12:04 on Apr 30, 2019 |
# ? Apr 30, 2019 11:39 |
|
uncle blog posted:I've been testing this site I'm working on, on different OS and browsers using browserstack. On Windows, both IE and Chrome makes the scrollbar overlap the page, effectively hiding part of it. Is this a normal Windows-thing I have to account for somehow, or have I goofed up?
|
# ? Apr 30, 2019 17:26 |
|
drat Facebook is getting rewritten in React. I would love to be part of that
|
# ? Apr 30, 2019 19:19 |
|
Grump posted:drat Facebook is getting rewritten in React. I would love to be part of that this sounds weird to me, since React is a Facebook product. They haven't even been using it in their flagship site?
|
# ? Apr 30, 2019 19:21 |
|
They use Reason + React for messenger.com, but the Facebook stuff is much older than React
|
# ? Apr 30, 2019 19:38 |
|
Yeah. They still use PHP for the frontend last I checked And have been doing new features in React
|
# ? Apr 30, 2019 19:39 |
|
Guys and gals, that weird error/ Redux context thing with a third party component that I was tearing my hair out was actually a flaw in the third-party component not being compatible with the latest react-redux. I had upgraded packages around the same time as I moved some stuff around--so I assumed it was me moving stuff. It was really frustrating but wow I know a lot more about redux and react now. Thanks again for all your help with looking into it though. There's still a lot about JS work that I am feeling around for but it's starting to click.
|
# ? May 2, 2019 02:45 |
|
How do you all handle shared components/functionality across apps? I’ve been trying to set up a monorepo using Lerna for the last two days and running into headaches at every turn. In the simplest version, if you have two apps that both use a button, what do you do? I used to have a private npm components library but it got super annoying to have to make separate PRs to the components library and n different apps that use that button when we wanted to update a prop or whatever. I want to be able to do everything in one PR.
|
# ? May 3, 2019 23:31 |
|
dantheman650 posted:How do you all handle shared components/functionality across apps? I’ve been trying to set up a monorepo using Lerna for the last two days and running into headaches at every turn. In the simplest version, if you have two apps that both use a button, what do you do? You can either have the headache of a monorepo or the headache of doing two commits*. Choose your own adventure! * Or, one could write a shell script that commits to both repos and then you only have to do one thing!
|
# ? May 4, 2019 20:36 |
|
|
# ? Jun 3, 2024 17:06 |
|
I'm just trying to do a basic Vue app where a component calls an API, gets true or false, and emits that to the parent. The parent tallies up the multiple true false values (as there are multiple children calling different APIs) and says how many are true. Is this a wrong way of doing things? Or something super innovative? Because I can't find anywhere to explain what I'm doing wrong as every basically tutorial either omits code in their instructions that's needed to work or just plain doesn't work anyway. my child component has code:
code:
|
# ? May 4, 2019 21:25 |