|
imho the Class-based Components can mess with the React mental model, because novices think (quite reasonably) "I defined a component as a class, which means an instance of this class is where the data's source-of-truth lives and that's where I mutate it". Nope, not at all. This is why they recommend using stateless functional components, because it doesn't mislead people down that path.
|
# ? Apr 6, 2021 00:17 |
|
|
# ? May 15, 2024 04:56 |
|
Yeah, class components let you keep state in instance variables which works right up until it doesn’t.
|
# ? Apr 6, 2021 00:47 |
|
As an answer to the question of why you would want information to travel up from child to parent, an example we run into a lot with Flutter that's a pain every time (I understand Flutter has a similar mental model to React's) is when you want a child's preferred size based on its own content to influence content or layout somewhere else nearby. For example, something like "if this text wants to take up more than X% of the available space in the row, use this smaller thing instead of the usual image for its neighbor". You can't do that by hoisting state because the string (which is the state) doesn't know how big it is, only the child element can tell you that. Typical advice for this kind of layout malarkey typically results in a lovely jittery two or three frames before you get a correct render. In Javascript this particular example is not so bad because there are functions for measuring text before you perform layout, so you *can* do it in a state higher up and pass the size down, but in Flutter there's no such thing. But there are similar situations in Javascript where you don't want to hoist out all the measuring stuff from the child element, so being able to call a function on the child from its parent (thereby having the child tell you what size it wants to be) would be way less user-hostile than React's opinionated thing.
|
# ? Apr 6, 2021 02:47 |
|
roomforthetuna posted:But there are similar situations in Javascript where you don't want to hoist out all the measuring stuff from the child element, so being able to call a function on the child from its parent (thereby having the child tell you what size it wants to be) would be way less user-hostile than React's opinionated thing. But you can do this? You just pass down a callback down a as a prop. It's a bad thing to do because you're adding a bunch of extra renders to everything, but you can do it. Roadie fucked around with this message at 10:20 on Apr 6, 2021 |
# ? Apr 6, 2021 03:09 |
|
Hey everyone quick question. WHere’s a good place to host a ExpressJs / Node.JS app that isn’t really anything crazy requirement wise? Same question for a Postgres db. I have it on AWS right now on my personal account but I think that’s a bit over excessive for a DB that will maybe have 5,000 records a year.
|
# ? Apr 6, 2021 13:16 |
|
TengenNewsEditor posted:Thanks, if you look at react as a 'view-only' framework, top-down unidirectional makes a lot more sense. I don't find it a pain at all. Again, could you provide a specific example of something that is giving you troubles? It's hard to help someone who is railing against vagaries. In the meantime, how the large apps I have done handle things in a very general way: * The bits of state that actually need to be global (ex: the User) are in contexts. The content of them can be accessed anywhere in the app with hooks, so I don't need to pass the user down as a prop all over the place. The same thing can be accomplished by using a state management solution like Redux, and connecting components that need the user to it. * All other data lives as close to where it needs to render. If there is a complex tree / lots of different things might use the same data in one part of the app, another context is created and hooks are again used to expose that data as needed without crazy prop drilling. * For complicated state changes in parts of the app due to lots of user interaction, useReducer is used to manage that state, again as close to the point it is needed as possible. There are cases where all your data / state is better off being global. That's why Redux (or other global state managers) exist. There are cases when your data / state is highly compartmentalized. That's why contexts and useState exist. There are cases when your data is both. That's why you can use both together. That's why I like React.
|
# ? Apr 6, 2021 13:36 |
|
Roadie posted:But you can do this? You just pass down a callback down a as a prop. To get the ability to call a function on a child you can pass a callback down that contains a callback that the child immediately calls to register a callback with the parent so the parent can call something on the child if the parent keeps a copy of that thing. Obviously that's a fine and appropriate approach that isn't incredibly annoying at all.
|
# ? Apr 6, 2021 13:49 |
|
The child should “react” to the props passed by the parent, rather than the parent directly calling functions in the child. Otherwise you are just fighting the architecture.
|
# ? Apr 6, 2021 13:56 |
|
roomforthetuna posted:Passing a callback down gives you a way to have the child call the parent, it doesn't give you a way to have the parent call the child. Why would you need to call a function on a child? Change its property, get it to redraw, let react handle DOM updates. If your components are complicated enough that you need to call methods on them, they are too complex and you should probably break them down. The only reason I see for calling a method on a child component is to mess with the DOM and that's not something you should be doing in react.
|
# ? Apr 6, 2021 14:05 |
|
Lumpy posted:I don't find it a pain at all. Again, could you provide a specific example of something that is giving you troubles? It's hard to help someone who is railing against vagaries. That's helpful, thanks. Honestly although react does a good job of warning you it's a top-down only library, it's difficult to conceptualize how that's actually supposed to work when nearly all examples and tutorials online are fighting the framework. When I tried using it as a 'view only' library, I hit a few roadblocks and immediately gave up on it since it seemed like I was going against the grain. Once the thread convinced me that was the right way to go I went back to it and worked out the specific issues (which turned out to have nothing to do with react).
|
# ? Apr 6, 2021 14:09 |
Lumpy posted:I don't find it a pain at all. Again, could you provide a specific example of something that is giving you troubles? It's hard to help someone who is railing against vagaries. This follows my experience as well, for what it's worth. Context and hooks + pure components work very well for us.
|
|
# ? Apr 6, 2021 14:17 |
|
smackfu posted:The child should “react” to the props passed by the parent, rather than the parent directly calling functions in the child. Otherwise you are just fighting the architecture. go play outside Skyler posted:The only reason I see for calling a method on a child component is to mess with the DOM and that's not something you should be doing in react. Seems like we're going in circles here. 1. "Why would you want to do a thing that React doesn't do?" "Here's an example of why." 2. "Oh but you can do that kind of thing by passing a callback." "No you can't." 3. "Oh right, you shouldn't be using React like that, why would you want to?" quote:If your components are complicated enough that you need to call methods on them, they are too complex and you should probably break them down Anyway, it seems like we're agreeing at this point; if you might want to do that sort of thing you should avoid React or Flutter. Way ahead of you on avoiding React. Unfortunately Flutter's cross-platform compile, set of available libraries, and ability to not burn battery, make it tough to replace.
|
# ? Apr 6, 2021 14:22 |
So for your layout example, you're saying that's the children need to notify the parent of their rendered size? What's wrong with having them just call a setter provided from the parent context? You can wrap that in a debouncer that aggregates calls if you want to minimize rerenders. Rendered size is a weird part of application state that I'd not really considered part of actual informative state before, interesting.
|
|
# ? Apr 6, 2021 14:42 |
|
I am kind of curious what kind of app needs the child to tell the parent its size to layout, rather than using CSS. Even if React doesn’t work well for this particular use case, that doesn’t mean it is useless. Programmers have such strong opinions and they dig in so quickly.
|
# ? Apr 6, 2021 14:50 |
|
Osmosisch posted:So for your layout example, you're saying that's the children need to notify the parent of their rendered size? What's wrong with having them just call a setter provided from the parent context? You can wrap that in a debouncer that aggregates calls if you want to minimize rerenders. You could do the same thing by exposing some bare or static functions that the parent can call to do the measuring, but then you're losing the ability to use the same path for laying out a variety of children of different types, unless you start writing your own "factory and set of functions" wrappers, all of which could be avoided if you could just call functions on child instances, like you can if you use something that provides a bidirectional link between DOM elements and their associated classes (like Closure or [spits] Polymer). Calling a setter from the parent context is not that dissimilar to the thing of passing a callback that registers a callback - you're making the child remember something it doesn't really care about, and making the parent remember the state that isn't really part of its state, and also having to deal with the one pass where that state hasn't been provided yet. It just adds a whole bunch of complexity and cognitive load that shouldn't be there. I realize this sounds like a bizarre niche situation, but (especially with internationalizing strings) it comes up a surprising amount, like "if the string over there is too big to fit in the space available, shrink its font, but then to avoid looking LiKe ThAt SpOnGeBoB MeMe, also shrink the font in this *other* sibling component to the same size". There's a Flutter widget for this, "AutoSizeText", that works the way you suggest, but it means you get a frame or two of flicker of the wrong size where child A laid out in the bigger size first, child B figured out it needed to be smaller, parent got notified, everything rerenders (and if you have more complicated interactions, that change can trigger further changes on subsequent frames and it sucks). With a framework that doesn't have that aggressive top-down opinion, you can measure first and cut once.
|
# ? Apr 6, 2021 14:58 |
|
E: worthless post
xtal fucked around with this message at 18:02 on Apr 6, 2021 |
# ? Apr 6, 2021 15:07 |
|
I have never encountered a case where a child component's rendering size affected parent components in a way that couldn't be solved with good CSS rules. I could tell you to "lol learn CSS" but a more constructive suggestion I would have, would be to create a withLayoutUpdate() High-Order-Component, that adds a new "didDraw" callback property to every component using this. When your child component is finished rendering, call this callback and have your parent components listen on that event and redraw accordingly, I guess. Not sure of the specifics of how to implement that, but it seems like a way to do it. I understand this feels like a limitation to React and if I was in your case I'd be feeling like I'm just trying to find ways around React's architecture as well. But to me this is a small drawback in a sea of advantages the "framework" has, including but not limited to writing super simple layout code. Mind you, this is coming from a guy who spent years writing UI's in WinForms, jQuery, Cocoa (interface builder et. al) and WPF. I've seen it all, and I still cringe every time I look at the amount of loving boilerplate and complexity needed to do simple poo poo with WPF when I compare it to React. I still very much enjoy how React is extremely down-to-earth and simple to understand.
|
# ? Apr 6, 2021 15:37 |
|
roomforthetuna posted:Calling a setter from the parent context React doesn't give you external setter functions on components because that's what props are for. You write your components to do stuff when props change. Here's a real quick example using a helper hook: JavaScript code:
Roadie fucked around with this message at 19:13 on Apr 6, 2021 |
# ? Apr 6, 2021 17:55 |
|
sounds like a limitation of the display: table based layout
|
# ? Apr 6, 2021 18:22 |
|
If I need to make an http request via node, is axios still the gold standard?
|
# ? Apr 7, 2021 17:50 |
|
I used node-fetch the last time I did something and it seemed fine and I didn’t have to learn anything new.
|
# ? Apr 7, 2021 18:05 |
|
Can't you just use fetch by itself in node? I feel like I've used that.
|
# ? Apr 7, 2021 18:07 |
|
Yeah and I still use axios. Just used to it.
|
# ? Apr 7, 2021 18:27 |
|
Empress Brosephine posted:Can't you just use fetch by itself in node? I feel like I've used that. fetch isn't built-in to the standard library (there are a couple of npm libraries that emulate fetch, though). if fetch were built-in i could see the case for "why do i need a library for this", but since you're picking between libraries, may as well go with the slightly nicer one.
|
# ? Apr 7, 2021 18:35 |
|
I generally use node-fetch mostly to reduce mental overhead, but also because if you use any server-side rendering stuff you can then use a generic fetch set either way to do data fetching the same on the server and on the client.
|
# ? Apr 7, 2021 21:23 |
|
is svelte any good
|
# ? Apr 7, 2021 22:21 |
|
I got my first "SequelizeDatabaseError: out of memory" error las night on my D&D gambling game server, and now I'm scrambling to figure out what happened. Best I can tell, it was one of two issues: First, it's possible that I just have a memory leak that builds up over the weeks. I just recorded my server memory usage and will check on it periodically, to see if that could be the case. Annoyingly, AWS doesn't track RAM usage, but I can just console in and copy/paste my stats every few days, I guess. The other possibility is that it's because my DB usage tends to be real choppy. The DB only gets called at the end of each match (there's one big fight that all users are betting on the outcome of, and when it ends a bunch of money moves around all at once), so every few minutes I'm doing these huge masses of parallel finds/updates (should just be one per bettor, but there can be anywhere from 20 to 500+ bettors at any given time). Could that cause memory errors? And, related, is there some 'smart' way of doing mass updates using postgres/sequelize? Currently I just have a list of IDs that placed bets, and I just iterate through them, kicking off one async function call each that then makes a findOne DB call to get the user's info, then a single update to change their gold/winrate/etc. Is that something that's going to scale super badly as usernumbers climb? Is there some setting I need to enable or code I need to write to limit the rate these resolve at? Do I need to be doing something slightly more fancy, like running a single giant findAll({where:{id:[1,2,5,22,17...740,430,4]}}) to get my userinfos, instead of doing a bunch of one-offs? I'm pretty sure that even if I did that there's no way to mass-update DB entries, so it'd only be solving half the problem. I guess I could probably be doing more to limit the number of columns reported to me on these queries, does that make a significant difference? For reference, the 'out of memory' error came out of a simple 'findOne' call shot into a table of ~800 users without any other-table dependencies, so it's not that the query itself was in any way excessive.
|
# ? Apr 7, 2021 22:24 |
|
Is the database RDS or on the ec2 instance? If the former RDS definitely has memory related metrics. If the latter, I'd setup the cloud watch agent which will collect memory stats of the instance into cloud watch. Then you can see if the issue is database memory or your server code and better plan out a resolution. But just based on the error I'd assume it's the database having memory issues. RDS has a ton of metrics that will help investigate.
|
# ? Apr 7, 2021 22:47 |
|
necrotic posted:Is the database RDS or on the ec2 instance? If the former RDS definitely has memory related metrics. If the latter, I'd setup the cloud watch agent which will collect memory stats of the instance into cloud watch. It's on the instance. I'll take a look at CWA, though! The database is relatively recently added and not too huge yet, fwiw. Like, other than the ~800 user accounts there's a little bit of stat-tracking which was previously being stored via JSON text file. I'm actively avoiding advertising until I'm confident the server can survive a surge of attention/have some more user retention stuff set up
|
# ? Apr 8, 2021 01:16 |
|
Are there any strategies for creating an arbitrary number of react useState hooks? My goal is to define an abritrary set of buttons using an array like this: JavaScript code:
I'd like to use a loop or map to define a useState hook for each of those buttons and store the values/functions in their own arrays. JavaScript code:
JavaScript code:
I've got my components set up to accept these arrays but react won't let me do the useState initialization in a loop. Any thoughts?
|
# ? Apr 10, 2021 05:34 |
|
Make the state local to the button and create multiple buttons?
|
# ? Apr 10, 2021 05:46 |
|
I thought I'd take time during this quarantine to learn React, but somehow the constant threat of having me or people I care about dying wasn't conducive to learning a new skill. Now myself and my family have gotten their second doses, so I feel more relaxed and open to things that aren't doomscrolling. The last time I really tried was when React Hooks were brand new.
|
# ? Apr 10, 2021 22:08 |
|
Aren't classes in JS just syntactic sugar anyways?
|
# ? Apr 11, 2021 00:27 |
|
Yes.
|
# ? Apr 11, 2021 01:08 |
|
Yes, pretty common to write only with functional components now. Main thing that’s changed lately is that most of the other React related libraries now have their own hooks. https://react-redux.js.org/api/hooks https://reactrouter.com/web/api/Hooks https://formatjs.io/docs/react-intl/api/ Also, don’t use moment anymore.
|
# ? Apr 11, 2021 14:40 |
|
Hello, I'm an idiot who has a problem I don't even know how to begin to solve. I have a chart, it's basically a line chart. I have points for the chart (eg. [1,4], [20, 32]), and the line between the points is just a straight line connecting the points (the slope of the line does change every point). I need to let a user enter an x value, and based on this line chart, get a y value even if the value isn't present in the points by calculating it on the line it would fall on. Any ideas?
|
# ? Apr 12, 2021 01:45 |
|
Skyarb posted:Hello, I'm an idiot who has a problem I don't even know how to begin to solve. Here's a snippet that I worked out in the JS console and then I'll explain how it works. I hope it's similar to what you're describing... JavaScript code:
|
# ? Apr 12, 2021 02:18 |
|
xtal posted:Here's a snippet that I worked out in the JS console and then I'll explain how it works. I hope it's similar to what you're describing... This was similar to how I was thinking too, is there a library that does this? I know doing it myself is not too crazy but surely this is a problem that has been solved. Also thank you for the break down!
|
# ? Apr 12, 2021 02:26 |
|
Skyarb posted:This was similar to how I was thinking too, is there a library that does this? I know doing it myself is not too crazy but surely this is a problem that has been solved. Edit: Oh wrong language, got my threads confused. Anyway the phrase you're looking for is linear interpolation. https://numpy.org/doc/stable/reference/generated/numpy.interp.html HappyHippo fucked around with this message at 16:28 on Apr 12, 2021 |
# ? Apr 12, 2021 16:25 |
|
|
# ? May 15, 2024 04:56 |
|
Where can I read about js variable declarations that look like this:JavaScript code:
|
# ? Apr 12, 2021 20:38 |