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
Ape Fist
Feb 23, 2007

Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.
On an unrelated note, I've built a little project using Express, EJS, and TypeScript where I write the whole loving thing in TypeScript and then use gulp to compile the front & back end separately and then bundle the whole TypeScript front-end into a single JS file. Turns out manually transpiling typescript down to a bundled es5 file is a bunch of bullshit but now that I've got it working I'm chuffed with it. I'm going to see about integrating TypeORM into it to connect to MySQL and then I'll have a nice little full-stack starter kit for myself to use on whatever whacky personal projects I want to run. Which I'll never do, because I never have time, but its nice to dream.

Adbot
ADBOT LOVES YOU

prom candy
Dec 16, 2005

Only I may dance

Sergeant Rock posted:

If you can't write basic JS you need to change yur job description. Perhaps 'framework monkey'.

This is a pretty dumb take. Memorizing APIs you haven't used in ages doesn't make you a good developer.

Chenghiz
Feb 14, 2007

WHITE WHALE
HOLY GRAIL

Ape Fist posted:

So instances/roles like this are where actually having a very very very firm grasp of basic JS is extremely loving useful beause, if you're lucky, you MIGHT get to argue to have at least a basic gulp compiler to transpile your SCSS/ES6. Direct DOM manipulation using JS is a fairly normal part of my every day life but at least I _tend_ to be able to do it through ES6 where I at least have access to template strings and semi-coherent OO design principles which I prefer to use given that I adore TypeScript.

So basically you're doing direct dom manipulation because your job won't let you use a library.

Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



Chenghiz posted:

So basically you're doing direct dom manipulation because your job won't let you use a library.

Hey you gotta count those kilobytes!

*customer uploads 100s of 5 MB product photos for thumbnails*

gbut
Mar 28, 2008

😤I put the UN🇺🇳 in 🎊FUN🎉


Well, you should use an image processing service like imagx (or roll your own out). Even WordPress auro-resizes photos.

On the other hand, system designed so even idiots can use it, etc.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice
Has anyone used Storybook for a React project? What were your experiences, and would you do it again? I think I want to use it for a new project, but would love to hear other's takes on it.

prom candy
Dec 16, 2005

Only I may dance
I tried to set it up on a project about a year ago and gave up pretty quickly because it wasn't very turnkey with Typescript.

teen phone cutie
Jun 18, 2012

last year i rewrote something awful from scratch because i hate myself
I used it with CRA2 and TypeScript and it worked great!

Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



gbut posted:

Well, you should use an image processing service like imagx (or roll your own out). Even WordPress auro-resizes photos.

On the other hand, system designed so even idiots can use it, etc.

Well I'm making certain, possibly unfair, assumptions about the kind of place that would refuse to use a front-end framework and the kinds of blind spots they would have.

prom candy
Dec 16, 2005

Only I may dance

Grump posted:

I used it with CRA2 and TypeScript and it worked great!

CRA2 having first class support for Typescript is probably going to make a lot of things better. I was trying it with react-scripts-ts which I've since ejected. Kinda tempted to see if I can migrate my ejected app on to CRA2. The lack of hot-reloading makes me sad, although it looks like maybe that can be fixed with craco.

Dominoes
Sep 20, 2007

Hey dudes, check out this new Rust/wasm project, which attempts to standardize Rust's frontend ecosystem.

ddiddles
Oct 21, 2008

Roses are red, violets are blue, I'm a schizophrenic and so am I

Lumpy posted:

Has anyone used Storybook for a React project? What were your experiences, and would you do it again? I think I want to use it for a new project, but would love to hear other's takes on it.

It's nice, no need to set up a route to render your component you're building, just drop a .stories file and set up your props and you can set up a great overall view of the small bits of your app. Having a little control panel that lets you change props is really awesome.

Good luck if you have any sort of custom webpack stuff going, I was only able to get it to work with a new CRA repo, but didn't spend too much time trying to get a custom setup working.

Thermopyle
Jul 1, 2003

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

Dominoes posted:

Hey dudes, check out this new Rust/wasm project, which attempts to standardize Rust's frontend ecosystem.

Why would someone want to write Rust instead of, say, TypeScript?

Eleeleth
Jun 21, 2009

Damn, that is one suave eel.

Thermopyle posted:

Why would someone want to write Rust instead of, say, TypeScript?

Why would someone want to write TypeScript instead of, say, Rust?

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Eleeleth posted:

Why would someone want to write TypeScript instead of, say, Rust?

Because I don't know Rust?

Thermopyle
Jul 1, 2003

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

Eleeleth posted:

Why would someone want to write TypeScript instead of, say, Rust?

I think you're trying to be clever here, but I don't think you're as clever as you seem to think.

Web developers know TypeScript. What's the argument for them learning and using Rust?

Maybe there's a good argument for using Rust, maybe there's not, but asking what advantages it brings to the table over what people already know is a pretty good question to ask I think.

TypeScript is a pretty decent language, and not just in a good-for-a-web-language sense. It's not like in the old JS-is-our-only-option-and-oh-god-its-bad days.

I also know Rust, but I was just trying to give Dominoes a chance to convince people there are good reasons to try out his Rust web framework.

In other words:


Lumpy posted:

Because I don't know Rust?

Ape Fist
Feb 23, 2007

Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

Eleeleth posted:

Why would someone want to write TypeScript instead of, say, Rust?

With more and more people specializing on front-end and back-end choosing to take up TypeScript the language largely speaks for itself. It's neat, it's tidy, it brings most of the better aspects from C# down to JavaScript and given its meteoric rise up the charts its probably not just some pretender. Choosing to actively avoid it, as a Front End Dev is probably going to do you more harm than good in the short-to-long term.

Ape Fist
Feb 23, 2007

Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.
Update nobody asked for: TypeORM is nice and I'm definitely going to play around with it some more.

Queen Victorian
Feb 21, 2018

Hello fellow front-end dev goons! I'm here to ask some opinions but mostly vent about the possibility that my job could become way more difficult/annoying thanks to newfangled framework poo poo.

Some background: We have a browser-based enterprise SPA that primarily displays realtime data from remote sensors and has forms and stuff for configuring the sensors and the tests they conduct. There is no framework and never has been, which makes talking shop with other front-end people pretty fun because when asked which framework we use, I tell them jQuery :v:. But we also use D3, which is one of our most important libraries and what powers all our data visualization. I come from a design background, so I've come to be the de facto data visualization person, designing and also building the visualizations. This means I've spent the last few years getting really good at D3. It took a while to get over the cliff-like learning curve, but it's been well worth it.

Anyhow, it has been decided that we will hop on the React bandwagon. We very recently hired a new developer with React experience (no one on our very small team has React experience).

I'm very leery about this because of React's virtual DOM not playing nice with D3, which is all about touching and binding data to the DOM. However, there are some good solutions for using React and D3 together, my favorite of which involves cleanly dividing the DOM between React and D3 and never crossing the streams. This is the method that is generally favored by D3 people and lets you make framework-agnostic modules (because maybe next month your framework won't be cool anymore).

So we have the new guy familiarizing himself with the code and trying out React on some of the modules. I see him fiddling with a couple of the simpler D3 widgets and get curious.

:j:: Hey new guy, whatcha up to?
:): So I got this scatter plot working in React, check it out:
*shows off React module comprised of butchered fragments of D3 code shoehorned into JSX or whatever the gently caress*
:j:: Uhhhh... why did you rewrite it? I thought you were just putting it in a React wrapper.
:): I made it better! React is great at knowing what to update because of virtual DOM. No need for D3 to do that.
:j:: So how did you get the brush to work?
:): Oh, well D3 handles DOM updates for that and the axes because React can't do that. [I didn't even ask about transitions]
:j:: That's so... messy. If you're gonna let D3 touch the DOM in the first place, why not just let it handle ALL its own DOM poo poo and have a clean divide between D3 and React?
:): But why not do as much as possible in React? It's so great!
:j:: Well, ...hey, I'm not seeing the general update pattern anywhere. Why did you take that out?
:confused:: What's the general update pattern?
:j:: :suicide:

So this kid knows gently caress-all about D3 and is making React do horrible things to our D3 stuff and I'm terrified that this worst case scenario is what gets chosen for converting data viz modules and that my future is going to be writing React-specific modules with a fragmented implementation of D3 and fighting with it all the time because I'm used to having the complete D3 at my disposal and not used to being beholden to some framework with opinions.

Is this the futurepresent? We've been in our jQuery/no-framework time warp for so long I'm not sure what to expect. Don't get me wrong - I'm otherwise excited about trying out React because I'd love to be able to have more dynamic workflows and jettison a bunch of old lovely libraries and get new features up and running faster. And it's something I can add to my resume. It's the just the D3 integration part that has me worried. I'm hoping that when the boss gets back from vacation he'll tell new dev that D3 is allowed to touch the DOM and that we're not going to go with the React-fucks-over-D3 method.

Are there other D3 people here? Any D3/framework integration success stories? Am I right to be concerned or do I need to just suck it up and fully embrace the framework?

Dominoes
Sep 20, 2007

Thermopyle posted:

Why would someone want to write Rust instead of, say, TypeScript?
I'm focusing strictly on advantages of Rust; you could as easily write a list of disadvantages.

-Cargo and its ecosystem over npm
-Standardized API docs
-Compile-time error handling, with helpful messages
-Built-in unit testing
-Enums, structs, and generics
-Mandatory handling of cases that might fail, or have a missing value
-Better type inference
-Type system doesn't break down when using third-party modules
-Elegant serialization/deserialization

Dominoes fucked around with this message at 00:18 on Mar 27, 2019

Chenghiz
Feb 14, 2007

WHITE WHALE
HOLY GRAIL

Queen Victorian posted:

Am I right to be concerned or do I need to just suck it up and fully embrace the framework?

Speaking as someone who’s done a shitload of react and a bit of d3, I’d definitely lean towards letting d3 manage its own dom. Mixing the two seems bound to end in madness.

Gildiss
Aug 24, 2010

Grimey Drawer

Queen Victorian posted:

Are there other D3 people here? Any D3/framework integration success stories? Am I right to be concerned or do I need to just suck it up and fully embrace the framework?

On a cursory search there are plenty of articles laying out ways of going about using them together. Also one of them mentioned that only 8 of the 30 methods in D3 directly manipulate the DOM, the other 22 do not. So also check into exactly which methods need careful attention.

Also probably good since he doesn't have D3 and the rest don't have React to both come together and setup the standard for the compenents going forward and not just give him free reign on something he only has 50% of an answer to.

Gildiss fucked around with this message at 01:07 on Mar 27, 2019

gbut
Mar 28, 2008

😤I put the UN🇺🇳 in 🎊FUN🎉


Dominoes posted:

I'm focusing strictly on advantages of Rust; you could as easily write a list of disadvantages.


-Better type inference

TypeScript just pretends to have one.

Queen Victorian
Feb 21, 2018

Chenghiz posted:

Speaking as someone who’s done a shitload of react and a bit of d3, I’d definitely lean towards letting d3 manage its own dom. Mixing the two seems bound to end in madness.

Yeah, letting D3 handle its own DOM is my desired solution and the one I'm going to push hard for when I talk to the boss about this. At the very least, I'd accept react-faux-dom, but it honestly seems like unnecessary overhead that you add if you really don't want React to have to share the DOM (which I give no fucks about).

And yeah, I was quite concerned when I saw the cherrypicking that was going on with which framework/library was going to handle the DOM for this or that aspect of the graph :psyduck: christ why would you do that? I don't know jack poo poo about React, but one thing I've picked up is that you don't loving mix DOM responsibilities within a component because then the virtual DOM gets out of whack and it's a clusterfuck.

Gildiss posted:

On a cursory search there are plenty of articles laying out ways of going about using them together. Also one of them mentioned that only 8 of the 30 methods in D3 directly manipulate the DOM, the other 22 do not. So also check into exactly which methods need careful attention.

Oh yeah, a shitton of D3's functionality is completely under the hood and not at all concerned with the DOM - this is why a valid (but inappropriate for our use case) approach is to use D3 for calculations and React/framework of choice for rendering. If you're a React dev and have an existing React app and want to add the power of D3 to it, this is the way to go. But in our application, we've come to rely heavily on D3's DOM-handling functionality to render our visualizations, so it makes way more sense for us to let D3 keep doing its DOM stuff and not refactor everything because React.

I've done a ton of reading on this topic, and it's kinda dismaying to see how much bad writing there is on D3-framework integration, with the worst being patronizing advice to just use some framework-compatible charting library instead because D3 is hard and obtuse and you shouldn't bother. Luckily there is good material on React integration written by people who also understand D3.

quote:

Also probably good since he doesn't have D3 and the rest don't have React to both come together and setup the standard for the compenents going forward and not just give him free reign on something he only has 50% of an answer to.

Indeed - I do want all of us to be happy and for our way forward to play to all our strengths, and I believe the way to do that is to just not let React and D3 interfere with each other, which is the polar opposite of what the new dev is thinking.

Ape Fist
Feb 23, 2007

Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

gbut posted:

TypeScript just pretends to have one.

By this logic all typescript is pretend. The interfaces are pretend. The decorators are pretend.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Queen Victorian posted:

Yeah, letting D3 handle its own DOM is my desired solution and the one I'm going to push hard for when I talk to the boss about this. At the very least, I'd accept react-faux-dom, but it honestly seems like unnecessary overhead that you add if you really don't want React to have to share the DOM (which I give no fucks about).

And yeah, I was quite concerned when I saw the cherrypicking that was going on with which framework/library was going to handle the DOM for this or that aspect of the graph :psyduck: christ why would you do that? I don't know jack poo poo about React, but one thing I've picked up is that you don't loving mix DOM responsibilities within a component because then the virtual DOM gets out of whack and it's a clusterfuck.


Oh yeah, a shitton of D3's functionality is completely under the hood and not at all concerned with the DOM - this is why a valid (but inappropriate for our use case) approach is to use D3 for calculations and React/framework of choice for rendering. If you're a React dev and have an existing React app and want to add the power of D3 to it, this is the way to go. But in our application, we've come to rely heavily on D3's DOM-handling functionality to render our visualizations, so it makes way more sense for us to let D3 keep doing its DOM stuff and not refactor everything because React.

I've done a ton of reading on this topic, and it's kinda dismaying to see how much bad writing there is on D3-framework integration, with the worst being patronizing advice to just use some framework-compatible charting library instead because D3 is hard and obtuse and you shouldn't bother. Luckily there is good material on React integration written by people who also understand D3.


Indeed - I do want all of us to be happy and for our way forward to play to all our strengths, and I believe the way to do that is to just not let React and D3 interfere with each other, which is the polar opposite of what the new dev is thinking.

The way I did this was to have D3 render to a virtual DOM, and had a wrapped React component render that. D3 was none the wiser, and there was no fighting. I’ll look up the exact thing I did when I get to work.

EDIT: react-faux-dom is what I used!

Lumpy fucked around with this message at 12:58 on Mar 27, 2019

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



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

huhu
Feb 24, 2006

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.

Are you learning both or how they work together? Have you used a type system before?

teen phone cutie
Jun 18, 2012

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

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.

For tutorials I'm not sure, but I'll post this blog post as a starting point for deciphering errors:

https://medium.com/innovation-and-technology/deciphering-typescripts-react-errors-8704cc9ef402

When it comes to composing React HOCs, I think @types/recompose is the way to go

JavaScript code:
import {compose} from 'recompose'

/** 
   * inner props being the props that get passed to the component directly 
   * outter props being all props that this component inherits, from HOCs and from the parent
   */
export default compose<OutterProps, InnerProps>(
   HOC1,
   HOC2
)(MyComponent)
^^^ That will give you some nice auto-completion and errors when passing down incorrect props

Queen Victorian
Feb 21, 2018

Lumpy posted:

The way I did this was to have D3 render to a virtual DOM, and had a wrapped React component render that. D3 was none the wiser, and there was no fighting. I’ll look up the exact thing I did when I get to work.

EDIT: react-faux-dom is what I used!

Oh yeah, this is one of the two acceptable solutions I've been entertaining (I think I mentioned it earlier), even though it seems like quite a bit of extra overhead for the sake of not having to split DOM responsibilities - I feel like it'd be better to just cut to the chase and let D3 do its thing in clearly designated zones than to essentially carry out update actions twice on a page full of live-updating animated graphs.

Also, I need to get to the bottom of how feature-complete react-faux-dom really is (been seeing conflicting accounts), and see how performant it is with lots of poo poo going on.

Performance-wise, I'm not particularly concerned with D3 touching the DOM because the data-join enter-update-exit pattern works quite similarly to the virtual DOM - they both detect the data points that have changed, and update only the nodes affiliated with those data points so you don't have any ham-fisted wasteful overwriting going on (looking at you, jQuery).

With or without react-faux-dom, I still want to pursue super clean and obvious boundaries to keep the data visualization stuff agnostic and self-contained. There are a few views that could use consolidation - instead of a dozen inter-dependent D3 widgets just hanging out on the view, I'd instead want to unify them under a single module, which then becomes a single D3 DOM zone and wrapped by React (instead of a dozen separate ones).

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

huhu posted:

Are you learning both or how they work together? Have you used a type system before?

Just Typescript. I've familiarity with type systems from years of Objective-C and messing around with Elm.

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

Queen Victorian posted:

Oh yeah, this is one of the two acceptable solutions I've been entertaining (I think I mentioned it earlier), even though it seems like quite a bit of extra overhead for the sake of not having to split DOM responsibilities - I feel like it'd be better to just cut to the chase and let D3 do its thing in clearly designated zones than to essentially carry out update actions twice on a page full of live-updating animated graphs.

Also, I need to get to the bottom of how feature-complete react-faux-dom really is (been seeing conflicting accounts), and see how performant it is with lots of poo poo going on.

Performance-wise, I'm not particularly concerned with D3 touching the DOM because the data-join enter-update-exit pattern works quite similarly to the virtual DOM - they both detect the data points that have changed, and update only the nodes affiliated with those data points so you don't have any ham-fisted wasteful overwriting going on (looking at you, jQuery).

With or without react-faux-dom, I still want to pursue super clean and obvious boundaries to keep the data visualization stuff agnostic and self-contained. There are a few views that could use consolidation - instead of a dozen inter-dependent D3 widgets just hanging out on the view, I'd instead want to unify them under a single module, which then becomes a single D3 DOM zone and wrapped by React (instead of a dozen separate ones).

May be a stupid question, but did you look at any of the libraries for React-D3 integration? I think there are a couple that try to solve this problem, though I can't speak to how good they are at is (https://react-d3-library.github.io/ looks like it might have its poo poo together?)

teen phone cutie
Jun 18, 2012

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

Lumpy posted:

Just Typescript. I've familiarity with type systems from years of Objective-C and messing around with Elm.

In that case, I think you won't have much trouble. The React part of it isn't suuuuper crazy. Your components will end up looking something like

code:
interface Props {
  message: string;
  optionalMessage?: string;
}

interface State: {
  shouldShowButton: boolean;
}

class MyComponent extends React.PureComponent<Props, State>  {
  state: State = {
    shouldShowButton: false,
  }

  render() {
    return (
      <React.Fragment>
        <div>{props.message}</div>
        {props.optionalMessage} && <div>{optionalMessage}</div>
        {this.state.shouldShowButton} && <button />
       </React.Fragment>
     )
  }
}

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Grump posted:

In that case, I think you won't have much trouble. The React part of it isn't suuuuper crazy. Your components will end up looking something like

code:
interface Props {
  message: string;
  optionalMessage?: string;
}

interface State: {
  shouldShowButton: boolean;
}

class MyComponent extends React.PureComponent<Props, State>  {
  state: State = {
    shouldShowButton: false,
  }

  render() {
    return (
      <React.Fragment>
        <div>{props.message}</div>
        {props.optionalMessage} && <div>{optionalMessage}</div>
        {this.state.shouldShowButton} && <button />
       </React.Fragment>
     )
  }
}

Cool. What do functional components look like? Also, you have to use relative imports when you use TypeScript? :smith:

Dominoes
Sep 20, 2007

JavaScript code:
const theFunc = ({param1, param2}: {param1: string, param2: number}) => (
    <div>
        <h1>Content</h1>
    </div>
)
Or with the ability to perform calculations outside view code:
JavaScript code:
const theFunc = ({param1, param2}: {param1: string, param2: number}) => {
    const content = "Content"
    return (
        <div>
            <h1>{content}</h1>
        </div>
    )
}
The func sig can get quite verbose due to duplicating the param names. Anyone know a way around this? Note that you can pass in the second part separately. Ideal example:
JavaScript code:
const theFunc = (param1: string, param2: number) => (
// ...

teen phone cutie
Jun 18, 2012

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

Lumpy posted:

Cool. What do functional components look like? Also, you have to use relative imports when you use TypeScript? :smith:

Yeah CRA2 forces you to use relative imports for some dumb loving reason. You can get around that though with https://github.com/ds300/patch-package, which is a package that lets you change the node_modules code and applies the changes at build time

Just remove lines 127-133 here: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/scripts/utils/verifyTypeScriptSetup.js#L127

And then in your tsconfig.json

JavaScript code:
    "rootDir": "src",
    "baseUrl": ".",
    "paths": {
      "src/*": [
        "src/*"
      ]
    },
And that should allow you to do

JavaScript code:
import {hello} from 'src/components/whatever'
I write functional components like

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

teen phone cutie fucked around with this message at 16:39 on Mar 27, 2019

prom candy
Dec 16, 2005

Only I may dance

Lumpy posted:

Cool. What do functional components look like? Also, you have to use relative imports when you use TypeScript? :smith:

code:
interface Props {
  name: string;
  age: number;
}

export default function Person({ name, age }: Props) {
  const [nicknames, setNicknames] = useState<string[]>([]);
  const [isCool, setIsCool] = useState(false); // useState infers type here
  
  return (
    <SomeJSX>{...}</SomeJSX>
  )
}
With create-react-app v2 and typescript you have to use relative imports but luckily you can use craco to get around that without having to eject.

First add tsconfig.paths.json to your project root:

code:
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}
then update tsconfig.json and add
pre:
"extends": "./tsconfig.paths.json",
to the top. then edit craco.config.js and add this block:

code:
module.exports = {
  webpack: {
    alias: {
      '@': path.resolve(__dirname, 'src/'),
    },
  }
}
Then you can import like this:

code:
import MyComponent from '@/components/MyComponent';
Where @ is an alias for your src dir. (Or do what Grump said)

Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



huhu posted:

Are you learning both or how they work together? Have you used a type system before?

JavaScript has a (rather limited) type system. It just also has a lot of coercion between types :v:

Munkeymon fucked around with this message at 18:34 on Mar 27, 2019

uncle blog
Nov 18, 2012

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?

Adbot
ADBOT LOVES YOU

Queen Victorian
Feb 21, 2018

dupersaurus posted:

May be a stupid question, but did you look at any of the libraries for React-D3 integration? I think there are a couple that try to solve this problem, though I can't speak to how good they are at is (https://react-d3-library.github.io/ looks like it might have its poo poo together?)

The three issues with that particular library are:
- Incomplete set of D3 features
- Was not updated to work with D3 v4
- Is dead

I've looked at all the integration libraries I've been able to dig up on Google, and all the ones that are not straight up charting libraries have one or more of the above issues, mostly the being dead one. The shift to v4 did a pretty good job of killing them. Upgrading our poo poo to v4 was a loving chore, and that was my job. Can't imagine going through that for a hobby project, so I don't blame the authors for abandoning them.

And the charting libraries, which make up the surviving integration libraries, won't do because I can't very well tell a charting library to whip me up an interactive timeline slider that shows which chunks of data that have been loaded into a view from a data set that covers a particular period of time, with two independent brushes, one being for selecting sections of additional data to load into the view, and the other to control how much of the loaded data is visible in the view. But if all we dealt with was line graphs and pie charts and maybe some tricky stacked bar graphs, then screw D3, I'd take the React charting library.

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