Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

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

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 18:52

smackfu: Jun 7, 2004

Yeah, class components let you keep state in instance variables which works right up until it doesn�t.

# ? Apr 6, 2021 00:47

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

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

Roadie: Jun 30, 2013

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

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

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

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

TengenNewsEditor posted:

Thanks, if you look at react as a 'view-only' framework, top-down unidirectional makes a lot more sense.

But if it's a view-only library why is it such a pain in the rear end to get external data into it? And if you're supposed to populate the top level component with a model of your entire application, how do you manage page re-renders for a nested state? Do you need a global state manager if you're not able to flatten out your application's model?

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

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Roadie posted:

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.

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.

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

smackfu: Jun 7, 2004

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

go play outside Skyler: Nov 7, 2005

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.

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.

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

TengenNewsEditor: Apr 3, 2004

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.

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.

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

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

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.

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.

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

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

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

That doesn't fix the problem, that's just trying to shuffle deckchairs on the titanic. If you need some layout information from a child component before you do the layout at the parent level, it doesn't matter how small you break down the components, you still need to ask a child component for some information. Breaking it down smaller just makes the communication problem worse.

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

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

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

smackfu: Jun 7, 2004

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

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

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.

Rendered size is a weird part of application state that I'd not really considered part of actual informative state before, interesting.

I mean *ideally* the child would be able to figure out its rendered size before it renders, to really minimize rerenders. (Which as I said, you can do in Javascript because there's text metrics functions available.)

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

xtal: Jan 9, 2011; by Fluffdaddy

E: worthless post

xtal fucked around with this message at 18:02 on Apr 6, 2021

# ? Apr 6, 2021 15:07

go play outside Skyler: Nov 7, 2005

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

Roadie: Jun 30, 2013

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:

import { usePreviousDistinct } from 'react-use';

const SomeComponent = ({ width, widthCallback }) => {
  const lastWidth = usePreviousDistinct(width);

  // Whenever width changes to a new distinct value (including initial render), do a thing
  useEffect(() => {
    widthCallback()
  }, [lastWidth]);

  return <div style={{ width }}>Some stuff here</div>;
}

Roadie fucked around with this message at 19:13 on Apr 6, 2021

# ? Apr 6, 2021 17:55

barkbell: Apr 14, 2006; woof

sounds like a limitation of the display: table based layout

# ? Apr 6, 2021 18:22

Skyarb: Sep 20, 2018; MMMPH MMMPPHH MPPPH GLUCK GLUCK OH SORRY I DIDNT SEE YOU THERE I WAS JUST CHOKING DOWN THIS BATTLEFIELD COCK DID YOU KNOW BATTLEFIELD IS THE BEST VIDEO GAME EVER NOW IF YOULL EXCUSE ME ILL GO BACK TO THIS BATTLECOCK

If I need to make an http request via node, is axios still the gold standard?

# ? Apr 7, 2021 17:50

smackfu: Jun 7, 2004

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

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

Can't you just use fetch by itself in node? I feel like I've used that.

# ? Apr 7, 2021 18:07

fsif: Jul 18, 2003

Yeah and I still use axios. Just used to it.

# ? Apr 7, 2021 18:27

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

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

Roadie: Jun 30, 2013

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

barkbell: Apr 14, 2006; woof

is svelte any good

# ? Apr 7, 2021 22:21

OtspIII: Sep 22, 2002

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

necrotic: Aug 2, 2005; I owe my brother big time for this!

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

OtspIII: Sep 22, 2002

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.

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.

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

Nohearum: Nov 2, 2013

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:


const buttonLabels = ['left','middle','right']

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:


const buttonVals = [valLeft, valMiddle,valRight ]

JavaScript code:


const buttonHdl = [hdlLeft, hdlMiddle,hdlRight ]

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

necrotic: Aug 2, 2005; I owe my brother big time for this!

Make the state local to the button and create multiple buttons?

# ? Apr 10, 2021 05:46

LifeLynx: Feb 27, 2001; Dang so this is like looking over his shoulder in real-time; Grimey Drawer

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.

Has anything changed in the past two years I should be aware of?
Have functional components with hooks totally replaced class components? I keep finding tutorials that start with class components and then halfway through go "Here's hooks, let's convert our To Do list project to use hooks! They're way better!"
What are the best tutorials out there these days?

# ? Apr 10, 2021 22:08

gbut: Mar 28, 2008; 😤I put the UN🇺🇳 in 🎊FUN🎉

Aren't classes in JS just syntactic sugar anyways?

# ? Apr 11, 2021 00:27

necrotic: Aug 2, 2005; I owe my brother big time for this!

Yes.

# ? Apr 11, 2021 01:08

smackfu: Jun 7, 2004

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

Skyarb: Sep 20, 2018; MMMPH MMMPPHH MPPPH GLUCK GLUCK OH SORRY I DIDNT SEE YOU THERE I WAS JUST CHOKING DOWN THIS BATTLEFIELD COCK DID YOU KNOW BATTLEFIELD IS THE BEST VIDEO GAME EVER NOW IF YOULL EXCUSE ME ILL GO BACK TO THIS BATTLECOCK

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

xtal: Jan 9, 2011; by Fluffdaddy

Skyarb posted:

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?

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:

// For testing
var input = 7, expectedResult = 70;
// Start with the list of coordinates
var coords = [ [1, 10], [5, 50], [10, 100] ];
// Find the two pairs that surround the provided input.
// For the pair BEFORE, REVERSE-sort the coords by the x value, and find the first pair where x is LOWER than the input.
var pairBefore = coords.sort(([ax, ay], [bx, by]) => ax < bx).find(([x, y]) => x < input);
// For the pair AFTER, PLAIN-sort the coords by the x value, and find the first pair where x is HIGHER than the input.
var pairAfter = coords.sort(([ax, ay], [bx, by]) => ax > bx).find(([x, y]) => x > input);
// Determine where the input is between [ax, input, bx] by input/(ax+bx).
var coefficient = input / (pairBefore[0] + pairAfter[0]);
// Determine the result by adding ay+by and multiplying by that coefficient.
var result = (pairBefore[1] + pairAfter[1]) * coefficient;

result == expectedResult // true

There might be unexpected edge cases if the data isn't that clean, such as having duplicate x coordinates. It could also be optimized by using this strategy to find the surrounding pairs: sort the coordinates only once by x value, then rather than calling `find` twice, use `reduce` to return the pair before and the pair after from one iteration.

# ? Apr 12, 2021 02:18

Skyarb: Sep 20, 2018; MMMPH MMMPPHH MPPPH GLUCK GLUCK OH SORRY I DIDNT SEE YOU THERE I WAS JUST CHOKING DOWN THIS BATTLEFIELD COCK DID YOU KNOW BATTLEFIELD IS THE BEST VIDEO GAME EVER NOW IF YOULL EXCUSE ME ILL GO BACK TO THIS BATTLECOCK

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...
JavaScript code:
// For testing
var input = 7, expectedResult = 70;
// Start with the list of coordinates
var coords = [ [1, 10], [5, 50], [10, 100] ];
// Find the two pairs that surround the provided input.
// For the pair BEFORE, REVERSE-sort the coords by the x value, and find the first pair where x is LOWER than the input.
var pairBefore = coords.sort(([ax, ay], [bx, by]) => ax < bx).find(([x, y]) => x < input);
// For the pair AFTER, PLAIN-sort the coords by the x value, and find the first pair where x is HIGHER than the input.
var pairAfter = coords.sort(([ax, ay], [bx, by]) => ax > bx).find(([x, y]) => x > input);
// Determine where the input is between [ax, input, bx] by input/(ax+bx).
var coefficient = input / (pairBefore[0] + pairAfter[0]);
// Determine the result by adding ay+by and multiplying by that coefficient.
var result = (pairBefore[1] + pairAfter[1]) * coefficient;

result == expectedResult // true
There might be unexpected edge cases if the data isn't that clean, such as having duplicate x coordinates. It could also be optimized by using this strategy to find the surrounding pairs: sort the coordinates only once by x value, then rather than calling `find` twice, use `reduce` to return the pair before and the pair after from one iteration.

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

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

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.

Also thank you for the break down!

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

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 18:52

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

Where can I read about js variable declarations that look like this:

JavaScript code:

const [a, b] = someObject;
const {something: c, d} = someOtherObject;

I know that the first line takes the properties a and b from someObject and assigns them to a and b, but I'm honestly not sure about the second line. If I knew the names of these styles of simultaneous declarations that would be a great start.

# ? Apr 12, 2021 20:38

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »