|
Nolgthorn posted:I think it will continue being slow forever until they replace it no matter what. It's not even slow if you're not doing expensive poo poo in your renders. I feel like there's been this crazy arms race lately to have the fastest renders, the smallest bundles, the lowest TTI, etc. etc. and meanwhile pretty much all the major solutions are good enough for most people in most cases without having to put a lot of thought into it. The only times I've ever had to do any real render janitoring (aside from memoizing expensive computations) is when I have very large lists of fairly complex components, and you'd get the same issue in pretty much any framework.
|
#
?
Nov 1, 2022 02:08
|
|
|
|
| # ? May 18, 2024 23:40 |
|
|
I have a few questions. Im more of a backend dev who dabbles in frontends from time to time. Does anyone have an open source example of a well designed react app? I feel since Ive learned on the fly my UIs feel a bit hacked together. Is there a tool to upgrade a legacy React app to Typescript?
|
|
#
?
Nov 1, 2022 02:51
|
|
|
Yeah, you don't have to worry about that render optimizatin stuff 99% of the times since all your screen is just a bunch of input fields and buttons that toggle some static content or whatever. Also, react react renders are actually really fast, so using React.useMemo prematurely will slow your app down, since it might take more time to compare all the props to determine whether you should do a rerender instead of just doing the rerender. There isn't really a tool afaik, it's just a process. You rename your flies, add the TS dependencies and a tsconfig.json file, and then set the TS rules to be very lax. Then you go through your files and start adding type annotations and making sure everything makes sense type-wise. Once you've done that, you can enable strict mode and live a happy life. Here's an article I found online which I've just summed up for you.
|
|
#
?
Nov 1, 2022 09:08
|
|
|
I think there was a tool I used once that converted PropTypes to types but I feel like it used any way to much.
|
|
#
?
Nov 1, 2022 12:35
|
|
|
dupersaurus posted:Thats not how it works, though? Of course it is. If a component re-renders all of it's child components re-render too, unless you wrap it in React.memo. ? Components re-render constantly, because of the way redux is built. So, basically your entire screen re-renders constantly as long as you are using the store for anything. Which you have to do because otherwise you're trying to hack the whole thing, modifying css properties manually, and that ends up being impossible. So you yearn for the days when basic javascript was the norm and react was still a sperm in the pseudointellectual sternum of your average development blog. Nolgthorn fucked around with this message at 01:50 on Nov 5, 2022 |
|
#
?
Nov 5, 2022 01:47
|
|
|
Nolgthorn posted:Of course it is. If a component re-renders all of it's child components re-render too, unless you wrap it in React.memo. ? Most re-renders are cheap, that's the point of React
|
|
#
?
Nov 5, 2022 02:21
|
|
|
They even specifically call out useMemo as performance-degrading if you use it for everything
|
|
#
?
Nov 5, 2022 02:46
|
|
|
prom candy posted:Most re-renders are cheap, that's the point of React Paint operations in the browser are the most expensive thing you can do, unless I've missed the boat about something.
|
|
#
?
Nov 5, 2022 03:44
|
|
|
Nolgthorn posted:Paint operations in the browser are the most expensive thing you can do, unless I've missed the boat about something. You missed the boat that theres a big difference between re-rendering a component (happens all the time) and actually committing changes to the DOM (only when something actually changes) Also painting is easy, its the layout that kills you
|
|
#
?
Nov 5, 2022 04:12
|
|
|
Nolgthorn posted:Paint operations in the browser are the most expensive thing you can do, unless I've missed the boat about something. Re-renders only commit changes. No changes = no repaints. The whole reason we all got hyped as gently caress about react in the first place is their little VDOM trick allowed view to be a function of state in a fairly performant way. Now we have new frameworks that are reactive without vdom (svelte, solid I think) and in some cases faster than React but React is still plenty fast for most applications. Unless you're doing expensive computations you don't need to janitor your renders in React.
|
|
#
?
Nov 5, 2022 04:44
|
|
|
dumping next.js 13 thoughts here because i don't have that many places to talk about javascript on the internet these days. i've been using it for a fun little spike project. super not production ready (like: lots of table stakes bugs, seriously, do not even think about trying to use it on something you want to ship sooner than spring 2023) but doing a spike in it really quickly shows how useful, but totally different, server components + suspense are. the big thing is that server components have basically a totally different runtime environment with a significantly different api and requires a way different way of thinking. for example: you can't read contexts in them (or use any hooks). so if you're used to having an AuthProvider that's tracking a user's logged in state so you can read it in any component, sorry, not happening. but what you can do is use the react server components "cache" mechanism. this is a way of having a cache for the lifetime of a single response. so you could have a function called `getCurrentUser()` that gets wrapped in the new react `cache()` function, and then call that from all your different components, and it will always be referencing the current user within that request. this is basically undocumented outside of next's docs, but they talk about it a bit here (https://beta.nextjs.org/docs/data-fetching/caching#per-request-caching), and the key thing is they've somehow gotten `fetch` to automatically do this caching (https://beta.nextjs.org/docs/data-fetching/fundamentals#automatic-fetch-request-deduping - they describe this as react doing the caching but i'm not really sure if that means react is monkey-patching it or what). i think this is a really interesting model to build around but also potentially hard to reason about! also it's kind of confusing that it's called "caching" when that collides with the other things you think about when you hear "caching" (especially in the next.js docs, since the whole framework is kinda built around caching data). the rationale behind this, fwiw, is that react streaming is basically built to not give a gently caress about what order anything happens in, and part of that is to not care about whether parent components have finished loading or anything. so the idea is that other than props, server components can't rely on anything else to get state from. i feel like once i understood that i understood why the hell this thing was built this way, but if you don't start from that principle this all seems like a mess, lol that said, i think the react ecosystem is heavily built around caching/deduplication, so hopefully these concepts won't be too hard for people to wrap their heads around. like, most people using redux are using some kind of entity abstraction that handles storing data by request and maybe handles deduplication, graphql has all kind of caching stuff, etc. and there is some part of my sicko brain that sees cache() and thinks "hell yes singletons are back in per-request form." the big problem is gonna be ecosystem catchup. imagine, say, react-intl. that thing currently works by wrapping your whole app in a context like `<IntlProvider language="en-US" strings={...}>` and then within your app using a component like `<FormattedMessage id="homepage.header" />`, which then gets the string for the language from the context. well, that ain't gonna work in server-side components. it's not too hard to imagine an alternative api that would work for that (just something like a factory for a cache()-wrapped function that returns the intl context for a given language, and then a <FormattedServerMessage> that accepts that intl context object), but, yknow, that api needs to get made, and every single react library you use now will need similar changes to adapt to server-side components (assuming the library is something that makes sense on the server; the rest i guess just need to staple "use client" to the top of the index file and call it a day). i have many more words about this i want to type, but the problems are abstract enough to describe that i know this all just sounds like gibberish to anyone who hasn't started working with next.js 13, so i'll stop there for now lol. again, very fun to go try to spike something out in it Roadie posted:For me, the one big thing still totally missing in Next as compared to Remix is form handling. Not "mutations" or any other fancy poo poo done through frontend JS, just plain form handling that will work right with a form POST from a static page. next.js 13's "mutations" page is currently has a big "RFC coming soon!" thing at the top (https://beta.nextjs.org/docs/data-fetching/mutating) and i wouldn't be surprised if this is what they move to. right now they say "just write an api endpoint, do a client-side fetch(), and then refresh via the router," so they just gotta replace the first two parts with a nice form POST wrapper and they've recreated remix actions
|
|
#
?
Nov 5, 2022 04:45
|
|
|
I haven't jumped into RSC yet because it still feels so likely to change in big ways but I gotta say the ergonomics of Remix feel a lot more understandable to me than any of the RSC stuff. I've only worked with Remix a bit but the very clear line between client and server is nice. I don't know if I'm ready to live in a world where that line is extremely blurred.
|
|
#
?
Nov 5, 2022 05:15
|
|
|
Good writeup, I read the whole post. I also really like Next.js and am following its development closely. Server components seem like a great idea, but yeah, like you said, the whole ecosystem needs to catch up. Intl libraries, auth libraries, etc. Because of this, my mental model for server components right now is that they're like getServerSideProps functions that don't have to be at the top level. So when I'm playing around with next 13, I'm just using them as data providers pretty much, and do everything else in client components that they create. In retrospect, the thing that bothered me about getServerSideProps was that it had to be at the top level of a page, so it had to know about what its child components might need, and the child components just had to trust that something above them will provide them with the props from the server. In my experience, frontend components really want to be colocated with their data sources. That's what's really exciting about server components to me. That, and the layouts/suspense stuff, where a component doesn't have to manage its own loading state. I've had enough of writing try { setIdLoading(true); const { data } = await fetch('/endpoint') } catch (e) { } finally { setIsLoading(false) } tyvm. There are some weird things, like you said, where you don't have access to context and other client-side stuff. I haven't built anything serious in next 13 yet, but so far it seems that you just need to be able to fetch the user based on their auth cookie and you should have everything you need on the server side. Maybe, maybe not. Monkey patching the fetch function is really weird though. I wish they'd just provide their own. Also, why are you able to write server components as async functions or as sync functions with the use hook? That's weird. It's also weird that you can't mark components as server components with 'use server' or something. I like monorepos and I'd like to have some server components defined in libraries, but there doesn't seem to be a way of doing that right now. it's interesting how in some ways server components are really similar to php lol, you just fetch stuff in the component then spit out some html with some css.
|
|
#
?
Nov 5, 2022 10:22
|
|
|
hey mom its 420 posted:it's interesting how in some ways server components are really similar to php lol, you just fetch stuff in the component then spit out some html with some css. It's not PHP until I can create an SQL injection vulnerability inside a span tag
|
|
#
?
Nov 5, 2022 14:32
|
|
|
So I'm going to begrudgingly try to learn React. I am coming from both an Angular and Vue background. I'm looking at the tic-tac-toe example in the docs and have a few questions. This, like so many tutorials, is all one file, how do you break it up? Also, like so many tutorials, it's in .js, isn't .jsx the preferred format? What even is the advantage of jsx anyway?
|
|
#
?
Nov 5, 2022 20:21
|
|
|
quote:Also, like so many tutorials, it's in .js, isn't .jsx the preferred format? What even is the advantage of jsx anyway? It doesn't actually matter. JSX is kind of a lexical signal to say "This file contains weird poo poo like HTML markup, and is intended to do so." where .JS should be exclusively normal, regular javascript. There's a very good argument to be made that src/client/components/[ComponentName]/componentName.jsx is unnecessary because what else could that file possibly be? But at the end of the day it doesn't matter and doesn't change anything at all. Bundlers are smart enough to figure it out. Your linter is smart enough to figure it out. Your IDE is smart enough to figure it out. Even your import statements are smart enough to figure it out. It's exclusively for your own human eyeballs to know at a glance what the file contains. quote:This, like so many tutorials, is all one file, how do you break it up? Ask ten people and you'll get ten answers. For my own sake, anything that is exclusive to a component, and will not and cannot be used anywhere else, goes in src/client/components/[ComponentName]. CSS goes in a CSS folder and imported. Hooks go in a hooks folder and imported. State goes in a state folder and imported. Any function that can be abstracted out to be reused goes in a utils file and imported. I know people(also me, 5 years ago) that keep every single thing required to render a component all in the same file because it means they can open up react devtools, right-click the component and click inspect and know that the cause of their bug is somewhere in this file. Those people are out of their fuckin' minds, but they exist.
|
|
#
?
Nov 5, 2022 20:43
|
|
|
Vincent Valentine posted:Ask ten people and you'll get ten answers. Sorry, I meant from a technical level, not a theoretical one.
|
|
#
?
Nov 5, 2022 21:07
|
|
|
The Merkinman posted:This, like so many tutorials, is all one file, how do you break it up? Post the link of the tutorial though
|
|
#
?
Nov 5, 2022 21:20
|
|
|
The Merkinman posted:Sorry, I meant from a technical level, not a theoretical one. Its just JavaScript imports, you can put everything in one file or every function in a separate file, it doesnt matter from a technical perspective.
|
|
#
?
Nov 6, 2022 00:28
|
|
|
Vincent Valentine posted:It doesn't actually matter. JSX is kind of a lexical signal to say "This file contains weird poo poo like HTML markup, and is intended to do so." where .JS should be exclusively normal, regular javascript. There's a very good argument to be made that src/client/components/[ComponentName]/componentName.jsx is unnecessary because what else could that file possibly be? But at the end of the day it doesn't matter and doesn't change anything at all. Bundlers are smart enough to figure it out. Your linter is smart enough to figure it out. Your IDE is smart enough to figure it out. Even your import statements are smart enough to figure it out. It's exclusively for your own human eyeballs to know at a glance what the file contains. This is all true but the actual correct file extension to use for React components is .tsx
|
|
#
?
Nov 6, 2022 04:37
|
|
|
For data analysis and data science, what's currently the go to stack these days for front-end development for visualization and analysis of large datasets? How would real developers go about creating front-ends for this? Currently I just create static visualizations in Jupyter notebook or for smaller datasets we can use Tableau but we're exploring using something like Voila / Panel for Jupyter which lets you run dashboards from within a Jupyter notebook so that we can share a more interactive report / analysis. Only thing is this seems a little too ad-hoc / duct-taped together so trying to get an idea of the current "state of the art" for how real front end devs would do this. Data here is a big mix of stuff, including geo, time-series and some customer marketing data. Currently we pull from Spark into python pandas dataframes and do whatever cleaning/transformation and then use viz libraries like plotly, seaborn etc to create static plots. For Tableau, we typically get tables setup in Apache Impala but this requires some normalization which isn't always easy because we don't always have a straight-forward schema. The dataops folks are deploying a new Cloudera Data Platform instance soon which has a bunch of built in data science notebooks / visualizations and dashboards, but haven't really tested to see if they are any good. I've seen ELK stacks used for this (i.e. pull and denormalize data into an elasticsearch index, serve visualizations in Kibana) because of its speed, but we use Solr which to my knowledge only has a really old kibana port called Banana which doesn't seem like its used anymore. edit: caveat upfront I'm a BI analyst who's mainly self taught in the DS/DA space but I've got an interest in UX/UI and data viz so trying to learn more to get an idea of this space. Oysters Autobio fucked around with this message at 21:11 on Nov 6, 2022 |
|
#
?
Nov 6, 2022 20:01
|
|
|
Oysters Autobio posted:For data analysis and data science, what's currently the go to stack these days for front-end development for visualization and analysis of large datasets? How would real developers go about creating front-ends for this? Theres nothing really separating any of the frameworks, my company uses vue and react but really its personal preference. For graphing, d3 is the gold standard but its a bit of a bear to use, though there are packages that use it under the hood but present an easier interface. We also use Highcharts which is pretty good, but you might have to fork over money for a license.
|
|
#
?
Nov 6, 2022 22:59
|
|
|
The Merkinman posted:So I'm going to begrudgingly try to learn React. I am coming from both an Angular and Vue background. Make sure you are using the React BETA docs site, as the other one is way outdated and "wrong" in many ways. https://beta.reactjs.org/learn
|
|
#
?
Nov 7, 2022 17:44
|
|
|
Lumpy posted:Make sure you are using the React BETA docs site, as the other one is way outdated and "wrong" in many ways. Yeah I'd tried and bounced off of the original docs with the tic tac toe example but the beta docs are really really good
|
|
#
?
Nov 8, 2022 16:30
|
|
|
Lumpy posted:You should watch this video! so i finally got around to watching this video and I've learned 2 things: 1. You can get contexts to behave performantly without useSyncExternalStore. That method is just a convenience function that eliminates like 4 lines, like some other poster said 2. You can make it also make it generic so that you can mimic something like createSlice from redux toolkit So I'm kinda confused about useSyncExternalStore. I love the video because it taught me you can make contexts faster with just a little more code which I didn't know, but this hook isn't breaking new ground? 
|
|
#
?
Nov 8, 2022 22:22
|
|
|
I have a question that seems simple, but I can't for the life of me figure it out, and due to the terms involved, I can't  it very well. In our app, we have a translation file named en.json it has keys and values! We import it like so:code:
|
|
#
?
Nov 9, 2022 20:11
|
|
|
create a module as a wrapper that imports the json and then exports the object?
|
|
#
?
Nov 9, 2022 20:17
|
|
|
Lumpy posted:Make sure you are using the React BETA docs site, as the other one is way outdated and "wrong" in many ways. I'm still reading through them, but thanks so much for this. This seems to be clicking much better than the original docs. I'm guessing the way people write React apps has changed over the years with newer syntax kind of like Vue 3's (optional) Composition API? I know React's {} VS Angular and Vue's {{}} will trip up my muscle memory as well as [prop]="value" VS :prop="value" VS prop={value}, but oh well. I wish I could go back in time and tell my younger self to choose React instead of Angular for my company because of how career destroying that decision has been. The Merkinman fucked around with this message at 22:08 on Nov 17, 2022 |
|
#
?
Nov 12, 2022 19:22
|
|
|
Spime Wrangler posted:As a solo developer I've had good experiences with django on the backend (full send using the ORM and and django-rest-framework). Projects mostly in the 20-50k LOC range with low user numbers and minimal performance requirements. Following up on this after a month and a half. Cookiecutter-django: Awesome stack, some design decisions I changed, otherwise great right out of the box. OpenAPI-generator: Very annoying to get this working, the typescript modules are all over the place, it seems like there's work to standardize around one interface but between needing to janitor java and the dogshit documentation I dumped it. Landed on an API workflow that goes DRF-Spectactular (turnkey in cookiecutter) => schema.yml => Orval.js => Fully typed frontend client. All my ts types are controlled by my drf serializers and view definitions. The autogenerated client consumes and emits fully typed objects. No runtime checks and I have to remember to regenerate my schemas/client after updating any serializers or views, but that's been a very predictable process so far. Probably not as tight a system as trpc, but I'm not ready to give up my django security blanket yet. Vue3: script setup lang="ts" is wonderful. Composables and Pinia are awesome. I used vue-class-component and vue-property-decorator exclusively for my last few projects, and Vue3 has all the good parts of those tools but with much better ts support and fewer quirks. Bonus review: Tailwind-UI. Coming from bootstrap-vue I was concerned it wasn't going to be fully featured enough, but it's been great to use and well worth my company's $200 or whatever.
|
|
#
?
Nov 18, 2022 23:47
|
|
|
https://twitter.com/corg_e/status/1595287073547862018 lmao
|
|
#
?
Nov 23, 2022 14:19
|
|
|
Wow I have never heard of this guy before and after reading his tweets for 30 seconds I loving hate him. The internet is amazing!!
|
|
#
?
Nov 23, 2022 14:47
|
|
|
camoseven posted:Wow I have never heard of this guy before and after reading his tweets for 30 seconds I loving hate him. The internet is amazing!! I'm pretty sure the question he's asking here is literally "how do I figure out if a string starts from a specific set of characters in javascript" also because the backend already does what it's supposed to do for this part of search
|
|
#
?
Nov 23, 2022 15:18
|
|
|
Googled this guy, and he's apparently a famous security guy - ios\playstation 3 hacks under his belt. All the respect in the world for different disciplines in IT being whole other worlds, but this guys tweets read like his parent's got him a job because 'he built his own pc.' Wtf am I missing?
|
|
#
?
Nov 23, 2022 18:33
|
|
|
bobua posted:Googled this guy, and he's apparently a famous security guy - ios\playstation 3 hacks under his belt. The part where he just copied and pasted some stuff he saw on IRC in channels where people were collectively working to jailbreak iphones and playstations and took credit for a bunch of other people's work
|
|
#
?
Nov 23, 2022 23:50
|
|
|
Also I dont really see how his experience is at all relevant to fixing Twitter. I guess thats the problem with messing with Musk, he might call your bluff because he doesnt know better.
|
|
#
?
Nov 24, 2022 01:23
|
|
|
Okay React Friends. Tell me why this is a terrible, terrible idea:JavaScript code:
|
|
#
?
Dec 6, 2022 19:42
|
|
|
Lumpy posted:Okay React Friends. Tell me why this is a terrible, terrible idea: I think that's pretty much how FontAwesome does it
|
|
#
?
Dec 6, 2022 19:50
|
|
|
dupersaurus posted:I think that's pretty much how FontAwesome does it From mucking about in their internals earlier this morning, they actually seem to do an object that has a pathData property (and a bunch of other stuff you'd need) that goes into their FontAwesomeIcon component as the "icon" prop and I think they make an SVG inside of that, iterating over pathData. Which is an option as well for me, but just using SVG files as-is without having to do anything to them (other than add the export lines in a single place) is very compelling.
|
|
#
?
Dec 6, 2022 20:05
|
|
|
Lumpy posted:Okay React Friends. Tell me why this is a terrible, terrible idea: The only thing which weirds me out here is const star = Star() because calling the component directly as a function is something you just never do with React components. If it was const star = <Star /> I would have no objections at all.
|
|
#
?
Dec 11, 2022 19:20
|
|
|
|
| # ? May 18, 2024 23:40 |
|
|
I've had success simply exporting the svg as a react component, importing it somewhere else, using it. Why do you need to call it like a function? The extension of my svgs have typically been .tsx though so we are doing something different.
|
|
#
?
Dec 15, 2022 03:09
|
|