|
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.
|
# ? Mar 24, 2019 22:37 |
|
|
# ? Jun 6, 2024 19:40 |
|
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.
|
# ? Mar 25, 2019 04:01 |
|
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.
|
# ? Mar 25, 2019 14:36 |
|
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*
|
# ? Mar 25, 2019 15:55 |
|
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.
|
# ? Mar 25, 2019 17:05 |
|
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.
|
# ? Mar 25, 2019 19:51 |
|
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.
|
# ? Mar 25, 2019 19:57 |
|
I used it with CRA2 and TypeScript and it worked great!
|
# ? Mar 25, 2019 20:09 |
|
gbut posted:Well, you should use an image processing service like imagx (or roll your own out). Even WordPress auro-resizes photos. 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.
|
# ? Mar 25, 2019 20:45 |
|
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.
|
# ? Mar 25, 2019 21:20 |
|
Hey dudes, check out this new Rust/wasm project, which attempts to standardize Rust's frontend ecosystem.
|
# ? Mar 25, 2019 21:24 |
|
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.
|
# ? Mar 25, 2019 21:42 |
|
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?
|
# ? Mar 26, 2019 19:31 |
|
Thermopyle posted:Why would someone want to write Rust instead of, say, TypeScript? Why would someone want to write TypeScript instead of, say, Rust?
|
# ? Mar 26, 2019 20:14 |
|
Eleeleth posted:Why would someone want to write TypeScript instead of, say, Rust? Because I don't know Rust?
|
# ? Mar 26, 2019 20:21 |
|
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?
|
# ? Mar 26, 2019 20:32 |
|
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.
|
# ? Mar 26, 2019 20:56 |
|
Update nobody asked for: TypeORM is nice and I'm definitely going to play around with it some more.
|
# ? Mar 26, 2019 22:15 |
|
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 . 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. : 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* : 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. : 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] : 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! : Well, ...hey, I'm not seeing the general update pattern anywhere. Why did you take that out? : What's the general update pattern? : 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 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?
|
# ? Mar 26, 2019 23:42 |
|
Thermopyle posted:Why would someone want to write Rust instead of, say, TypeScript? -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 |
# ? Mar 27, 2019 00:14 |
|
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.
|
# ? Mar 27, 2019 00:46 |
|
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 |
# ? Mar 27, 2019 01:03 |
|
Dominoes posted:I'm focusing strictly on advantages of Rust; you could as easily write a list of disadvantages. TypeScript just pretends to have one.
|
# ? Mar 27, 2019 01:29 |
|
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 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.
|
# ? Mar 27, 2019 04:18 |
|
gbut posted:TypeScript just pretends to have one. By this logic all typescript is pretend. The interfaces are pretend. The decorators are pretend.
|
# ? Mar 27, 2019 07:15 |
|
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). 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 |
# ? Mar 27, 2019 12:56 |
|
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.
|
# ? Mar 27, 2019 14:14 |
|
Lumpy posted:My turn for a question! Are you learning both or how they work together? Have you used a type system before?
|
# ? Mar 27, 2019 14:45 |
|
Lumpy posted:My turn for a question! 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:
|
# ? Mar 27, 2019 14:57 |
|
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. 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).
|
# ? Mar 27, 2019 15:13 |
|
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.
|
# ? Mar 27, 2019 15:19 |
|
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. 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?)
|
# ? Mar 27, 2019 15:31 |
|
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:
|
# ? Mar 27, 2019 15:33 |
|
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 Cool. What do functional components look like? Also, you have to use relative imports when you use TypeScript?
|
# ? Mar 27, 2019 15:57 |
|
JavaScript code:
JavaScript code:
JavaScript code:
|
# ? Mar 27, 2019 16:28 |
|
Lumpy posted:Cool. What do functional components look like? Also, you have to use relative imports when you use TypeScript? 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:
JavaScript code:
JavaScript code:
teen phone cutie fucked around with this message at 16:39 on Mar 27, 2019 |
# ? Mar 27, 2019 16:32 |
|
Lumpy posted:Cool. What do functional components look like? Also, you have to use relative imports when you use TypeScript? code:
First add tsconfig.paths.json to your project root: code:
pre:"extends": "./tsconfig.paths.json", code:
code:
|
# ? Mar 27, 2019 16:40 |
|
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 Munkeymon fucked around with this message at 18:34 on Mar 27, 2019 |
# ? Mar 27, 2019 16:40 |
|
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:
The app is not ejected by the way. Could this be the issue?
|
# ? Mar 27, 2019 17:43 |
|
|
# ? Jun 6, 2024 19:40 |
|
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.
|
# ? Mar 27, 2019 19:45 |