|
uncle blog posted:I'm trying to learn to write tests in React. Right now I have a single test for one component. Whenever i try to run the tests, Jest gives me an error about how it can't find an imported resource in a different component, which I'm not testing. This has me puzzled. There's a lot of possibilities depending on your code and setup. Does StationCard import StationList directly or indirectly in any way? If so, you may want to stub out StationList if your test are not relevant to it. If you did intend that, if you're writing typescript or whatever, it could also be that your regular code runs through typescript/babel one way and your tests are run a different way and you have to reconcile the two configs. For example one may expect you to use ES6 style imports
|
# ? Mar 27, 2019 19:46 |
|
|
# ? Jun 9, 2024 02:55 |
|
Grump posted:
StatelessComponent is deprecated! Yay for web development! code:
Lumpy posted:My turn for a question! The typescript docs are pretty good. Don't forget to read through the "What's New" section for each version. There's descriptions of how to use new features and why they were added. As far as using it with React, this is a pretty great resource: https://github.com/sw-yx/react-typescript-cheatsheet
|
# ? Mar 28, 2019 00:39 |
|
I'm getting to the point where my urge to say "gently caress it" and stop learning typescript is kicking it. But this time I will harass you guys and you will carry me over the finish line of types! So I have a hook for "form stuff". Here's what it would look like in plain old JS: JavaScript code:
Thermopyle posted:
I think this will be great once I already know this stuff... =) EDIT: although I just found the event stuff in there, so I guess it's useful now! EDIT 2: Type '(event: any) => void' is missing the following properties from type 'FormEvent<HTMLFormElement>': nativeEvent, currentTarget, target, bubbles, and 11 more. How does one type a for submit event? And more importantly, how does one know where to look for this stuff? EDIT 3: Hot reloading doesn't work when there is a type error, so I have to quit the dev server and start it again... I think I really hate trying to learn Typescript. EDIT 4: JavaScript code:
If I do this: JavaScript code:
Lumpy fucked around with this message at 15:35 on Mar 28, 2019 |
# ? Mar 28, 2019 14:38 |
|
There is React.ChangeEvent<HTMLInputElement> which should work for most cases for events Typing hooks goes something like JavaScript code:
|
# ? Mar 28, 2019 15:28 |
|
Do you/could you pass initial values to your hook? If you did then I think you would start to get some type inference for that, and also use the generic to help you type other stuffcode:
|
# ? Mar 28, 2019 15:54 |
|
prom candy posted:Do you/could you pass initial values to your hook? If you did then I think you would start to get some type inference for that, and also use the generic to help you type other stuff This is helpful, thanks. That said, if I do this: JavaScript code:
At least hot reloading seems to have just started working again for some reason, so I'm going to soldier on! Despite the fact that I'd be almost done if I just did this in plain JS....
|
# ? Mar 28, 2019 16:25 |
|
You don't use a type system because it saves you time now, you use a type system because it saves you 2x (at least) the time later. I think maybe for handleChange you could try using a type like React.FormEvent<HTMLElement>. You can also typecast: const target = event.target as HTMLElement; The type system is usually very smart but sometimes you're smarter and you have to tell it what's what. Although sometimes you just think you're smarter and it was really right all along.
|
# ? Mar 28, 2019 16:56 |
|
prom candy posted:You don't use a type system because it saves you time now, you use a type system because it saves you 2x (at least) the time later. Oh, I know. That's why I'm sticking with it this time. Even if it kills me. It's all starting to click now; it's mainly the impatience of knowing plain JS gets one of the "end goals" done fast. Learning Elm was fun, as I couldn't bypass parts of it, so the errors and whatnot were taken in stride.
|
# ? Mar 28, 2019 17:26 |
|
Ugh setting this D3/React integration straight looks like it's going to harder than I thought. Boss was way less knowledgeable about React DOM rendering than I had assumed and straight up didn't get why I was throwing red flags at him over the new dev's cavalier DOM-stream-crossing in his attempt to integrate the D3 code or why it would be most desirable for our use case to keep React and D3 fully separate rather than tangled together in framework widgets. Now I'm all worried that boss is going to actually go with the new kid's method (which he just cargo culted from React fanboys on Medium who also know nothing about D3) and screw me over and screw up our entire data visualization paradigm. If it comes to pass that, despite having been here for five years, my concerns are dismissed and we go with this noob who's been on the job for three weeks, then I guess I'll just start responding to all the recruiters who keep messaging me on LinkedIn because that's a sure as gently caress sign I'm being disrespected and need a new job. I hope it doesn't come to that, though. Surely it won't. I guess I'll now be making a presentation for our upcoming sessions on learning/discussing React in which I will be explaining the correct way (D3-oriented approach in which React isn't allowed to interfere with D3) to integrate. Would an analogy in which React is East Germany and D3 is West Berlin be too flippant/insulting? It's just so spot on.
|
# ? Mar 28, 2019 17:31 |
|
You're kinda coming off as having a problem with React in general (understandably since it's loving with your poo poo) but it probably won't be taken well because React is insanely popular and also really good. Maybe I'm reading you wrong here and you're just annoyed that no one wants to listen to your correct take that they should be separated.
|
# ? Mar 28, 2019 18:16 |
|
Queen Victorian posted:
Having worked with both D3 and React separately, while I haven't had a project requirement to put both together as most of my D3 work has been in some legacy Angular apps, I do know that the real money and benefit from D3 is in its calculation and the DOM stuff is mostly there to help put everything you need in a one stop shop API. What I am saying is you might benefit more from updating your rendering toolkit and finding a way forward there and using the pieces of D3 you need outside of rendering. That is part of why V4 separated all the packages after all.
|
# ? Mar 28, 2019 18:39 |
|
prom candy posted:You're kinda coming off as having a problem with React in general (understandably since it's loving with your poo poo) but it probably won't be taken well because React is insanely popular and also really good. Maybe I'm reading you wrong here and you're just annoyed that no one wants to listen to your correct take that they should be separated. I really honestly want to NOT have a problem with React, but yes, it would certainly seem we are getting off on the wrong foot. In general, React seems a lot better for our general situation in terms of good consistent controllers and templates, not having a bloat of dumb bad libraries or a giant knotted up mess of jQuery, and having more streamlined development of things. The sticking point is how the D3 interaction has so far been handled with the new kid doing horrible poo poo with D3 and my boss not being concerned about it. I don't know if my boss is dismissing my concerns out of hand or just needs to go over the options more. Right now it really feels like I'm just not being heard because I'm not an authority on React and not even a "real" developer (I come from a pure design background and gradually shifted to heavier development duties, especially in regards to data visualizations - I suppose I have some insecurities about this) and that my concerns aren't even valid in the first place. I hope my worries are overblown and that React is cool and good and fun and that I can also continue my data visualization stuff without framework interference.
|
# ? Mar 28, 2019 18:56 |
|
Ahz posted:Having worked with both D3 and React separately, while I haven't had a project requirement to put both together as most of my D3 work has been in some legacy Angular apps, I do know that the real money and benefit from D3 is in its calculation and the DOM stuff is mostly there to help put everything you need in a one stop shop API. Yeah, there's certainly this angle, but my concerns here are getting myself locked into a framework and losing sight of how to do things without said framework and that pretty much all the documentation, tutorials, examples, etc. for D3 is written in agnostic D3-style JS and assume D3 rendering. All the official docs and resources switching to v4 is what finally forced us into upgrading our D3 version, because troubleshooting/researching stuff for our old v3 stuff was getting more and more difficult. If we go the way of React for rendering, lots of crucial resources become way less relatable.
|
# ? Mar 28, 2019 19:10 |
|
Yeah, it sounds like a bad situation either way. It does sound like they're excited about React (as they should be, React is awesome) and so if they start filing your complaints under "oh she just doesn't like the new thing" then I don't think you'll be listened to. I've worked with teammates in the past who just bristle at learning anything new and it's easy to ignore legitimate criticisms from them if you think they have an agenda. We pushed forward with React Native for way too long at my last job because the guy who had extremely legitimate criticisms of it had been complaining about every little thing from the start and so by the time he found the actual problems it was like "yeah ok bud" So yeah unfortunately I think your best way forward is to try to match their enthusiasm for React in general and focus on overcoming this specific issue. Also I am not really qualified to give interpersonal advice because I work from home as part of a two person distributed dev team, so I could be completely off the mark on everything here.
|
# ? Mar 28, 2019 19:13 |
|
Does anyone have hot reloading working with Create React App v2 and Typescript? I tried using the craco-plugin-hot-reload but I don't think it's compatible with Typescript. Not having hot reloading is brutal.
|
# ? Mar 28, 2019 19:15 |
|
I can't tell for sure without seeing your codebase, but the way you describe things leaving D3 separate from react is probably the play. That said, you may have to do the work yourself. Get react working in your code the way you want it, demonstrate to your boss why this is the good way to do it. Compare it to new guys way and give solid reasons why it's superior. It's going to be a rough sell no matter what just because so much time has already been spent.
|
# ? Mar 28, 2019 20:02 |
|
Queen Victorian posted:I really honestly want to NOT have a problem with React, but yes, it would certainly seem we are getting off on the wrong foot. In general, React seems a lot better for our general situation in terms of good consistent controllers and templates, not having a bloat of dumb bad libraries or a giant knotted up mess of jQuery, and having more streamlined development of things. The sticking point is how the D3 interaction has so far been handled with the new kid doing horrible poo poo with D3 and my boss not being concerned about it. I don't know if my boss is dismissing my concerns out of hand or just needs to go over the options more. Right now it really feels like I'm just not being heard because I'm not an authority on React and not even a "real" developer (I come from a pure design background and gradually shifted to heavier development duties, especially in regards to data visualizations - I suppose I have some insecurities about this) and that my concerns aren't even valid in the first place. I hope my worries are overblown and that React is cool and good and fun and that I can also continue my data visualization stuff without framework interference. Think from your bosses perspective - your boss probably doesn't know anything about react, and might be trying to grow a new employee. He also might be under time pressure to get a feature out the door. What I would do is I would ask myself the following questions: 1) Am I working on this right now with someone else, or is this dude doing his own thing? If the d3 integration is entirely this other dude's brainchild and has no relation to you, then gently caress it. You can raise the "hey, I've read on the internet that doing it this way is a bad idea" flag, but frankly, if you're not directly involved, it's really up to that dude and the boss to figure poo poo out. 2) Is the integration testable? Generally this mix of react/not react dom handling will make the project difficult to unit test - that should be a red flag. 3) Does are there other problems with the integration? (bugs, performace) Write tests demonstrating anything that doesn't work. Raise those as issues. Ask if you should help out with refactoring. 4) Is this code going to be the centerpiece for the product, or is it a one off thing? Think about how much D3 is being used- if this is a one-off. It may be appropriate just to get it to work. 5) If the integration works but is ugly or will produce maintenance problems in the future. If the integration is testable and functional, but just ugly, you can consider writing an adapter class to isolate your code from any potential changes to avoid having to rework things in the future, or do the pull request where it's refactored appropriately (although if you're at the point where you can test it easily and it performs as expected, might not be worth doing.)
|
# ? Mar 28, 2019 20:40 |
|
I have a conditional component which appears and fires off to a 3rd party API (not an ad/tracking server...). On my Firefox where I run uMatrix, this shows up as a CORS block. It's not, really but got me thinking that I should do some generalized error handling for this API callout. My question is, how can I catch and handle an error in reaching out to that service (since otherwise that part of the application will hang) and display a warning to the user? Hooks in React are baller but there's no componentDidCatch so a lot of the strategies I'm seeing won't work.
|
# ? Mar 29, 2019 01:43 |
|
Hed posted:I have a conditional component which appears and fires off to a 3rd party API (not an ad/tracking server...). On my Firefox where I run uMatrix, this shows up as a CORS block. It's not, really but got me thinking that I should do some generalized error handling for this API callout. You could possibly dispatch some Redux action when the catch block of the request fires and set has3rdPartyError state to true? Redux might be overkill depending on the size of the app, but it's definitely one possibility
|
# ? Mar 29, 2019 01:56 |
|
I love React and use it predominantly. I’m using Vue in a single project now and it’s actually pretty nice (still prefer React) but I’m surprised by how little anyone mentions it in this thread. Does anyone else use Vue at all or is it really this overshadowed by React?
|
# ? Mar 29, 2019 02:07 |
|
Ruggan posted:I love React and use it predominantly. I’m using Vue in a single project now and it’s actually pretty nice (still prefer React) but I’m surprised by how little anyone mentions it in this thread. Does anyone else use Vue at all or is it really this overshadowed by React? I've used Vue barely and feel like the opinion of this thread is that it's got an easier learning curve than React. That being said, when it comes to applying for jobs, the demand for React vs Vue is like 8:1, so people naturally lean towards React
|
# ? Mar 29, 2019 02:16 |
|
We use Vue almost exclusively at my work, and yes, it's easier to learn (as I'm told by people more proficient in React than me). We are also starting to build projects in React too now, as we ran into some issues in the past with Vue's strong opinions, and also to expand the accessible pool of front end devs, as per the comment above. More people know React, by far.
|
# ? Mar 29, 2019 02:43 |
|
Ruggan posted:I love React and use it predominantly. I’m using Vue in a single project now and it’s actually pretty nice (still prefer React) but I’m surprised by how little anyone mentions it in this thread. Does anyone else use Vue at all or is it really this overshadowed by React? I use Vue as my daily driver at work and have started using it for all my personal projects as well. I came from Angular, tho. I will go ahead and say I don't like React. I have been to classes, done many an online tutorial, but something about it makes me bounce right off of it. I think jsx is a large part of the reason. It just looks like an awful mess to me. I realize people say the same about Angular/Vue templating syntax as well, but yeah - can't get into React at all.
|
# ? Mar 29, 2019 02:50 |
We use Vue at work but locally I'd say the (modern) market is about 65/30/5: React/Vue/Angular and a lot of that Angular use is mostly Ionic.
|
|
# ? Mar 29, 2019 02:53 |
|
Ruggan posted:I love React and use it predominantly. I’m using Vue in a single project now and it’s actually pretty nice (still prefer React) but I’m surprised by how little anyone mentions it in this thread. Does anyone else use Vue at all or is it really this overshadowed by React?
|
# ? Mar 29, 2019 02:54 |
|
Well we had a bunch of discussion of React stuff today, and I think for the most part it's going to be more or less okay. Still a little bit leery on the D3 because nothing's confirmed yet, but we talked about both options (D3-centric, D3 gets to control DOM within its components vs React-rendered) and it's definitely not a one or the other choice, because in some cases, letting D3 fiddle with the DOM is stupid, and for other cases, letting React so much as touch D3's poo poo is stupid. So it's going to be case by case, and I'm thinking the way it's going to go down is render with React for components where D3 plays a minor/simple role, like a page with a pie chart and utilization bar on it, and then for components where the entire view is some huge analytics interface built out of interlocking D3 displays and filter components, that would go to D3. Otherwise, things I'm super excited about include Typescript, OOP, and finally cleaning up our goddamn horrible CSS with SASS and per-component styles. prom candy posted:Yeah, it sounds like a bad situation either way. It does sound like they're excited about React (as they should be, React is awesome) and so if they start filing your complaints under "oh she just doesn't like the new thing" then I don't think you'll be listened to. I've worked with teammates in the past who just bristle at learning anything new and it's easy to ignore legitimate criticisms from them if you think they have an agenda. We pushed forward with React Native for way too long at my last job because the guy who had extremely legitimate criticisms of it had been complaining about every little thing from the start and so by the time he found the actual problems it was like "yeah ok bud" So yeah unfortunately I think your best way forward is to try to match their enthusiasm for React in general and focus on overcoming this specific issue. Also I am not really qualified to give interpersonal advice because I work from home as part of a two person distributed dev team, so I could be completely off the mark on everything here. Oh, you are completely on point. I've been trying to maintain a good balance of relaying my excitement about React in general and communicating my very specific concern that is not about React or change or learning new things, just making sure we do D3 right in a way that doesn't kill my morale and totally throw me off track in my skill development. Oh, and out of sheer curiosity, what was the problem with React Native? We don't currently have a mobile app because 98% of our usage is desktops, but might go there eventually for the hell of it, or release some sort of companion/auxiliary app. Vincent Valentine posted:I can't tell for sure without seeing your codebase, but the way you describe things leaving D3 separate from react is probably the play. I've got an online course for React that I'll be hopping to in short order, and yeah, I'll be trying out proof of concept implementations as soon as I'm able. I'm aiming to lay out clear rules for D3 implementation, like when and how to do minor React-rendered widgets, and when and how to build a separate self-contained D3-rendered module. I think this will appease the powers that be because it's consistent, predictable, and organized. Luckily React exploration hasn't been a terribly huge sink of time and effort - it's mostly been the new guy dicking around with it while he learns the codebase. He doesn't have a terribly strong opinion on D3, luckily, and is more leaning towards the React-rendered method because he's a React guy. Bruegels Fuckbooks posted:Think from your bosses perspective - your boss probably doesn't know anything about react, and might be trying to grow a new employee. He also might be under time pressure to get a feature out the door. 1. The guy is so far just experimenting. And he's very new. And the thing about my D3/React integration of choice is that it's not really an integration at all - you build the D3 as a standalone module that you latch onto an element provided by a React component. That element becomes the entirety of D3's universe and D3 does not know that there is anything besides that element, and React doesn't know that D3 has latched onto that element, a la "It doesn't look like anything to me." 2. Oh yeah, it'll be very easy to run the React component without attaching the D3 module to it, and the D3 module will attach to any old div you tell it to attach to and can be run independently. I've previously developed analytics components in isolation on janky test rig backends (mostly so I could hook them up to a static data set and not be constantly hitting the API with queries) - I like this method of component testing. And writing dirty throwaway poo poo in PHP that no one will ever see or review is cathartic after spending so much time in production code JS land. 3. Haven't even started any integration/refactoring beyond tinkering. 4. I would argue that the D3 library is more essential to the UI than the framework, as we've been making do pretty handily without a framework so far, but would be pretty limited without D3 enabling us to build whatever the hell weird custom visualizations we need for our weird custom data. As this product matures, the data visualizations become more significant and sophisticated. React is one out of many framework options, but there's really no substitute for D3. If I had to build this UI with only one library, I would build it with D3. 5. I don't think it's ugly - there's a very clean boundary. And latching a self-contained D3 view to a React wrapper isn't so much a true integration, but rather a coexistence. They are separate and can be maintained and debugged separately. As for the components where we want to let React handle rendering (like on pages where D3 might provide a minor graph but data visualization isn't the defining feature of the view), that's just a matter of deploying the D3 library (sans DOM modules) in the context of React, which is new to us. For context, this is a niche enterprise product that collects all sorts of data from proprietary sensors. The front-end application part is only a fraction of it - I actually refer to it as a "browser-based interface" because it's just the user interface part of this huge system and happens to run in the browser (in some locked-down internal network, not on the internet). So lots of the "web app" rules of thumb don't really apply to us. The new guy brought up server-side rendering (which we don't currently do) and talked up some benefits, like faster initial load and therefore better SEO, at which point the rest of us laughed (I think he came from eCommerce - so VERY different priorities).
|
# ? Mar 29, 2019 05:04 |
|
The problem we ran into with React Native is that navigation is just not there. Maybe it's improved since then but it's something that I think made anything beyond rudimentary development really tough. Airbnb also a abandoned it last year which was pretty surprising. Of course, they have the resources to run two native teams.
|
# ? Mar 29, 2019 05:42 |
|
Adding React Native to your D3 / React integration concerns seems like a problem for another day.
|
# ? Mar 29, 2019 13:06 |
|
Ruggan posted:I love React and use it predominantly. I’m using Vue in a single project now and it’s actually pretty nice (still prefer React) but I’m surprised by how little anyone mentions it in this thread. Does anyone else use Vue at all or is it really this overshadowed by React? Just got back from Vue conf as we are moving our massive app to Vue from polymer (don't use polymer...), we looked at react as well but it's so syntactically different from the other two we decided against it for ease of transition. So far I've really enjoyed the tooling for Vue, none of the headaches we had before with polymer. We also have a few people who previously worked on large react projects and they seem happy with our choice, as many have said the learning curve for Vue is tiny.
|
# ? Mar 29, 2019 13:35 |
|
I've had a couple of interviews with Vue shops, sounds like it's getting some traction I'm interviewing for a react job next week. As a largely self-taught react dev, any suggestions on react concepts and things I should brief myself on?
|
# ? Mar 29, 2019 14:08 |
|
prom candy posted:The problem we ran into with React Native is that navigation is just not there. Maybe it's improved since then but it's something that I think made anything beyond rudimentary development really tough. Airbnb also a abandoned it last year which was pretty surprising. Of course, they have the resources to run two native teams. It's definitely improved in the last year. React-navigation is pretty solid now.
|
# ? Mar 29, 2019 14:39 |
|
smackfu posted:Adding React Native to your D3 / React integration concerns seems like a problem for another day. Oh it most definitely is - after the React decision, I remembered that React had a thing for building mobile apps (and we don't have a mobile app in TYOOL 2019) and read a couple pages about it. I'm thinking that just building something from the ground up is probably best for our case, as an optimal mobile app would be VERY different from our desktop-optimized thing, so it's not like we'd benefit from recycling components, and it would be nice to write a thing in not-JavaScript for a change. But it's not even in our pipeline at this point, just something we sometimes ponder.
|
# ? Mar 29, 2019 15:44 |
|
Another typescript question around figuring out how to type things. In Victory charts, there is this definition:JavaScript code:
What I am doing sans-ts is: JavaScript code:
When I do this without typing, I get this error: code:
And thanks for all the help so far everyone... I'm at the point where I am fairly comfortable now!
|
# ? Mar 30, 2019 18:46 |
|
So the problem here is that createContainer returns a React component with dynamic props that you have to supply. That error is saying "hey this prop doesn't match up with any props that <MyContainer /> expects. <MyContainer /> only expects a children prop" It looks like cursorDimensions is a prop in the Victory type definitions. Soo you'd have to do something like this props are exported here: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/victory/index.d.ts#L292 So you can do JavaScript code:
teen phone cutie fucked around with this message at 05:08 on Mar 31, 2019 |
# ? Mar 30, 2019 19:16 |
|
Does anyone know how to get es-lint to lint the inside of the script tags in Vue single file components?
|
# ? Mar 30, 2019 20:05 |
|
Ruggan posted:Does anyone know how to get es-lint to lint the inside of the script tags in Vue single file components? The default setup from creating a new Vue project with the cli does this. I can't recall what the exact setup is off the top of my head, but you could create a new project and take a look at the config. It might just be having to add the .vue extension to the list for eslint.
|
# ? Mar 30, 2019 21:50 |
|
So I think my main problem now is that eslint by default only lints js files, and there is no way to override that outside of some command line options when running the linter. We use Visual Studio professional for our project because it's been an MVC ASP.NET project through now, and whereas most other editors have eslint integration options (https://eslint.vuejs.org/user-guide/#editor-integrations) as far as I can tell there isn't a way to tell Visual Studio's built in linter to lint anything other than js files.
|
# ? Mar 30, 2019 23:34 |
|
Thermopyle posted:StatelessComponent is deprecated! Yay for web development! yeah I saw some React folks complaining about the TypeScript definition names and they must have changed it recently?
|
# ? Mar 31, 2019 05:09 |
|
Ruggan posted:So I think my main problem now is that eslint by default only lints js files, and there is no way to override that outside of some command line options when running the linter. and adding/jacking with an .eslintrc doesn't work?
|
# ? Mar 31, 2019 14:30 |
|
|
# ? Jun 9, 2024 02:55 |
|
HaB posted:and adding/jacking with an .eslintrc doesn't work? Per the eslint docs, the only way to specify file extensions to lint is through the command line. https://eslint.org/docs/user-guide/configuring#specifying-file-extensions-to-lint Maybe there’s a way to get it to work with glob patterns?
|
# ? Mar 31, 2019 14:45 |