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
Paranda
Jun 9, 2003

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.

code:
src/components/StationCard.test.js
Test suite failed to run

Cannot find module 'react-epic-spinners' from 'StationList.js'
Edit:
The app is not ejected by the way. Could this be the issue?

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

Adbot
ADBOT LOVES YOU

Thermopyle
Jul 1, 2003

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

Grump posted:

JavaScript code:
const MyComponent: React.StatelessComponent<Props, State> = (props) => { return <div/> }

StatelessComponent is deprecated! Yay for web development!

code:
const MyComponent: React.FC<DaProps> = (props) => <div>bloop</div>; 

Lumpy posted:

My turn for a question!

What is the best React+Typescript learning resource out there at the moment. Brand new app with nothing written, will be started with CRA and may or may not ever be ejected.

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

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice
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:
import { useState, useEffect } from 'react';

const useFormData = (submitHandler, validation) => {

  const [values, setValues] = useState({});
  const [errors, setErrors] = useState({});
  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleChange = (event) => {
   // stuff to update values when an input changes
  }

  const handleSubmit = (event) => {
    // run values through provided validation function, set errors
  }

  useEffect(() => {
    // if we are trying to submit and no errors, call provided submitHandler
  }, [errors]);

  return {
      handleChange,
      handleSubmit,
      values,
      errors,
    }
}
So my question is: How do I handle the type of the submit handler and validation functions? I know they will both take "an object" of some kind, and one will return "an object" of some kind. Using "any" seems to defeat the point. I know there is a 'Function' type as well.. is that the correct TS way to do this? To me it seems like hand-waving away the params and return types the same way 'any' does. Bonus question: How do I type those events since they are React synthetic ones?

Thermopyle posted:



As far as using it with React, this is a pretty great resource: https://github.com/sw-yx/react-typescript-cheatsheet

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. :suicide: 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:
const handleChange = ( event : React.ChangeEventHandler<HTMLInputElement> ) => {
        event.persist();
        ...
    }
Hmm: Property 'persist' does not exist on type '(event: ChangeEvent<Element>) => void' Okay. So make it a SyntheticEvent, and... Property 'name' does not exist on type 'EventTarget'.

If I do this:

JavaScript code:
const handleChange :  React.ChangeEventHandler<HTMLInputElement> = ( event ) => {
...

const handleSubmit = ( event  : React.FormEvent<HTMLFormElement> ) => {
...
Things work. But if I use the same typing syntax for both (if I move the handleChange type after the 'event' or move the handleSubmit event type where the other one is) things explode. According to the 'Form and Events' part of that guide linked, they should act the same? So why does it work one way and not the other? I am assuming this is some fundamental thing I am not understanding.

Lumpy fucked around with this message at 15:35 on Mar 28, 2019

teen phone cutie
Jun 18, 2012

last year i rewrote something awful from scratch because i hate myself
There is React.ChangeEvent<HTMLInputElement> which should work for most cases for events

Typing hooks goes something like

JavaScript code:
const [isOpen, setOpen] = useState<boolean>(false);
I would also look into Generics, which allow you to pass type arguments. So like, each time you invoke useFormState, you can implicitly tell it which types the form values should be

prom candy
Dec 16, 2005

Only I may dance
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

code:
function useFormData<Values>(
  submitHandler: (values: Values) => void, 
  validation: (values: Values) => void, 
  initialValues: Values
) {

  const [values, setValues] = useState(initialValues);
  const [errors, setErrors] = useState<{ [key: string]: string[] }>({});
  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleChange = (event: React.FormEvent) => {
    // stuff to update values when an input changes
  }

  const handleSubmit = (event: React.FormEvent<HTMLFormElement>) => {
    // run values through provided validation function, set errors
  }

  useEffect(() => {
    // if we are trying to submit and no errors, call provided submitHandler
  }, [errors]);

  return {
    handleChange,
    handleSubmit,
    values,
    errors,
  }
}
I'll be honest, i sometimes do just typecast the event arg to 'any'. I wouldn't do it in something i was planning on releasing but if i just need to do like e.preventDefault() or whatever I can be kinda lazy.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

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

code:
function useFormData<Values>(
  submitHandler: (values: Values) => void, 
  validation: (values: Values) => void, 
  initialValues: Values
) {

  const [values, setValues] = useState(initialValues);
  const [errors, setErrors] = useState<{ [key: string]: string[] }>({});
  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleChange = (event: React.FormEvent) => {
    // stuff to update values when an input changes
  }

  const handleSubmit = (event: React.FormEvent<HTMLFormElement>) => {
    // run values through provided validation function, set errors
  }

  useEffect(() => {
    // if we are trying to submit and no errors, call provided submitHandler
  }, [errors]);

  return {
    handleChange,
    handleSubmit,
    values,
    errors,
  }
}
I'll be honest, i sometimes do just typecast the event arg to 'any'. I wouldn't do it in something i was planning on releasing but if i just need to do like e.preventDefault() or whatever I can be kinda lazy.

This is helpful, thanks.

That said, if I do this:

JavaScript code:
const handleChange = (event: React.FormEvent) => {
        event.persist();
        const blah = event.target.name;
    }
I get Property 'name' does not exist on type 'EventTarget'. Seems from googling that everyone else on earth is confused by this and 90% of "solutions" just give me new and exciting errors.

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....

prom candy
Dec 16, 2005

Only I may dance
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.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

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.

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.

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.

Queen Victorian
Feb 21, 2018

:negative:

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.

prom candy
Dec 16, 2005

Only I may dance
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.

Ahz
Jun 17, 2001
PUT MY CART BACK? I'M BETTER THAN THAT AND YOU! WHERE IS MY BUTLER?!

Queen Victorian posted:

:negative:

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.

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.

Queen Victorian
Feb 21, 2018

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.

Queen Victorian
Feb 21, 2018

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.

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.

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.

prom candy
Dec 16, 2005

Only I may dance
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.

prom candy
Dec 16, 2005

Only I may dance
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.

Vincent Valentine
Feb 28, 2006

Murdertime

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.

Bruegels Fuckbooks
Sep 14, 2004

Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

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.)

Hed
Mar 31, 2004

Fun Shoe
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.

teen phone cutie
Jun 18, 2012

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

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.

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.

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

Ruggan
Feb 20, 2007
WHAT THAT SMELL LIKE?!


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?

teen phone cutie
Jun 18, 2012

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

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

gbut
Mar 28, 2008

😤I put the UN🇺🇳 in 🎊FUN🎉


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.

HaB
Jan 5, 2001

What are the odds?

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.

lunar detritus
May 6, 2009


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.

Dominoes
Sep 20, 2007

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 prefer react's integrated view syntax over templates.

Queen Victorian
Feb 21, 2018

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.

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.

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.
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.)

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).

prom candy
Dec 16, 2005

Only I may dance
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.

smackfu
Jun 7, 2004

Adding React Native to your D3 / React integration concerns seems like a problem for another day.

Dr. Krieger
Apr 9, 2010

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.

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.'
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?

Chenghiz
Feb 14, 2007

WHITE WHALE
HOLY GRAIL

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.

Queen Victorian
Feb 21, 2018

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.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice
Another typescript question around figuring out how to type things. In Victory charts, there is this definition:

JavaScript code:
export function createContainer<V, W>(
    c1: ContainerType,
    c2: ContainerType
  ): React.ComponentType<V & W>;
( definitions are here: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/victory/index.d.ts)

What I am doing sans-ts is:

JavaScript code:
const MyContainer  = createContainer("cursor", "voronoi");

<VictoryChart
  containerComponent={ <MyContainer  cursorDimension="x" /> }
  ..
/>
The things it's combining are 'VictoryCursorContainer' and 'VictoryVoronoiContainer'.

When I do this without typing, I get this error:

code:
TypeScript error: Type '{ cursorDimension: string; }' is not assignable to type 'IntrinsicAttributes & { children?: ReactNode; }'.
  Property 'cursorDimension' does not exist on type 'IntrinsicAttributes & { children?: ReactNode; }'.
So what do I type 'MyContainer' as, and given that set of definitions and my error, how do I figure that out so I don't have to bug you guys?

And thanks for all the help so far everyone... I'm at the point where I am fairly comfortable now!

teen phone cutie
Jun 18, 2012

last year i rewrote something awful from scratch because i hate myself
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:
import { VictoryCursorContainerProps, VictoryVoronoiContainerProps, createContainer } from 'victory';

/** now we're saying createContainer is a function that returns a React component that takes VictoryCursorContainerProps as props */
const MyContainer  = createContainer<VictoryCursorContainerProps, VictoryVoronoiContainerProps>("cursor", "voronoi");


teen phone cutie fucked around with this message at 05:08 on Mar 31, 2019

Ruggan
Feb 20, 2007
WHAT THAT SMELL LIKE?!


Does anyone know how to get es-lint to lint the inside of the script tags in Vue single file components?

HaB
Jan 5, 2001

What are the odds?

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.

Ruggan
Feb 20, 2007
WHAT THAT SMELL LIKE?!


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.

teen phone cutie
Jun 18, 2012

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

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?

HaB
Jan 5, 2001

What are the odds?

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.

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.

and adding/jacking with an .eslintrc doesn't work?

Adbot
ADBOT LOVES YOU

Ruggan
Feb 20, 2007
WHAT THAT SMELL LIKE?!


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?

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