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 »

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

haproxy can't route http requests, can it? nginx forwarding to node.js is fine

# ? Feb 12, 2017 22:03

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 14:05

Impotence: Nov 8, 2010; Lipstick Apathy

I use varnish for that role. I like varnish

# ? Feb 12, 2017 22:07

Ranzear: Jul 25, 2013

Suspicious Dish posted:

haproxy can't route http requests, can it? nginx forwarding to node.js is fine

It can do some really wild poo poo and I think it should just be in front of everything and anything. Wouldn't be hard to have it route to nginx by subdomain or something if you don't feel like parsing URIs.

I have haproxy terminating LetsEncrypt tls and splitting http and websockets between nginx and node.js. This lets me have both the (nginx+php served) pages and (node.js game server) websocket both on 80 or 443, so as long as you can hit the page you can hit the game server too instead of being on some strange port, and I don't have to touch certs in either nginx or node.

I'm still a filthy PHP user for normal scripty request antics though. Node is almost strictly a websocket application server for me, for shared javascript between client and server.

"Do one thing and do it well" right?

Ranzear fucked around with this message at 00:07 on Feb 13, 2017

# ? Feb 12, 2017 23:30

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

Haproxy can proxy basically anything. We used it for http and DB replica routing.

And people use node because they know front end JS so how bad can it be in the backend. When they say content like HTML I assume it's generated after hitting the DB.

# ? Feb 13, 2017 02:29

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

The only use case I can think of for writing even one line of code to serve a static file is to restrict access to the file in some way and I don't understand why people are weirded out by using nginx with Node (or Python or Ruby for that matter).

# ? Feb 13, 2017 16:37

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

Another benefit is great plugins like Naxsi to help prevent a bunch of attacks.

# ? Feb 13, 2017 17:18

porksmash: Sep 30, 2008

edit: wow wrong page

# ? Feb 13, 2017 18:14

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Munkeymon posted:

The only use case I can think of for writing even one line of code to serve a static file is to restrict access to the file in some way and I don't understand why people are weirded out by using nginx with Node (or Python or Ruby for that matter).

And even when you do that you should pipe it through to X-SendFile features to avoid the slower scripting Lang doing the file serving.

# ? Feb 13, 2017 22:18

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.

Munkeymon posted:

The only use case I can think of for writing even one line of code to serve a static file is to restrict access to the file in some way and I don't understand why people are weirded out by using nginx with Node (or Python or Ruby for that matter).

it's not that nginx is bad. nginx is great. the problem is that anything is great behind nginx. if node really scaled, then nginix would be a nice-to-have instead of a requirement.

# ? Feb 15, 2017 13:40

peepsalot: Apr 24, 2007; ��PEEP THIS...
��BITCH!

Is Comet still a thing that exists and people have even heard of? Or should I be using websockets now, or some other thing for server push functionality.

The application is that I want to stream binary data from server to clientside script and visualize it in realtime. The data is from an accelerometer with up to 3200 samples/s, similar to a raw audio stream.
I'm looking for minimal latency, minimal bandwidth overhead, and high update rate.

# ? Feb 15, 2017 17:41

Ranzear: Jul 25, 2013

peepsalot posted:

The data is from an accelerometer with up to 3200 samples/s, similar to a raw audio stream.

Now there's a term I haven't heard in a long time. Websocket is the way to go, yes, but regardless of whether a websocket could handle such data (it totally can), do you really need to display 3200 samples a second? If not, 120/second is nothing to a websocket and enough for anybody. Else, pack some few ms worth of samples together and throw them across to save some overhead.

If they're already in a JS datastructure of any sort, JSON them and chuck them across as strings, no sweat. Websockets are supposed to do binary streams too, but most browser websocket APIs are ... futzy about it.

# ? Feb 16, 2017 04:32

peepsalot: Apr 24, 2007; ��PEEP THIS...
��BITCH!

Ranzear posted:

Do you really need to display 3200 samples a second? If not, 120/second is nothing to a websocket and enough for anybody. Else, pack some few ms worth of samples together and throw them across to save some overhead.

If they're already in a JS datastructure of any sort, JSON them and chuck them across as strings, no sweat. Websockets are supposed to do binary streams too, but most browser websocket APIs are ... futzy about it.

The purpose of this project is to act more or less like a digital storage oscilloscope. How many of those samples are visible at any given time is dependent on how much the user is zoomed in, and if it is autoscrolling but either way I need to capture all samples so that there can be an option to save a full log to disk, or to pause and zoom in on a particular event, scroll through different points in time etc.

The data is coming from a microcontroller (esp8266) so all data is raw binary with minimal processing so as not to overload the MCU with JSON processing etc.

# ? Feb 16, 2017 21:49

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

peepsalot posted:

The purpose of this project is to act more or less like a digital storage oscilloscope. How many of those samples are visible at any given time is dependent on how much the user is zoomed in, and if it is autoscrolling but either way I need to capture all samples so that there can be an option to save a full log to disk, or to pause and zoom in on a particular event, scroll through different points in time etc.

The data is coming from a microcontroller (esp8266) so all data is raw binary with minimal processing so as not to overload the MCU with JSON processing etc.

You will likely run into issues if you try updating the DOM every 0.31ms. If you need that data at that granularity, I'd do batch updates via websocket every few 100ms, and do DOM updates then. Also, watch out for running out of memory. Chromes V8 engine can only allocate ~1.5gb of memory to a single tab before making GBS threads itself.

# ? Feb 16, 2017 22:01

Tres Burritos: Sep 3, 2009

Skandranon posted:

You will likely run into issues if you try updating the DOM every 0.31ms. If you need that data at that granularity, I'd do batch updates via websocket every few 100ms, and do DOM updates then. Also, watch out for running out of memory. Chromes V8 engine can only allocate ~1.5gb of memory to a single tab before making GBS threads itself.

You absolutely would not want to use the DOM for this, however if you've got the stomach for it you should be able to make some canvas WebGL stuff that would fit the bill. As far as storage goes you can fit a whole lotta gigs in the indexeddb.

# ? Feb 16, 2017 22:27

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

I thought indexeddb storage limits varied pretty wildly because unrestricted size databases in browsers is insanely stupid. Like from 5 to 10mb not gigabytes

# ? Feb 17, 2017 02:17

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

Oh right you can request an arbitrary amount for private ones or whatever. So not a guarantee.

# ? Feb 17, 2017 02:19

ROFLburger: Jan 12, 2006

Anyone have any suggestions or experience with a comprehensive(ish) component library? Anything like http://www.material-ui.com/

There's plenty of libraries with specialized components, but I can't seem to find many larger, more generalized libraries like Material-UI

# ? Feb 17, 2017 17:12

ROFLburger: Jan 12, 2006

Bruegels Fuckbooks posted:

I'm just going to post this without comment:
https://thefullsnack.com/don-t-serve-static-files-with-nodejs-31666462f79c#.ynw7kcwer

Besides being poorly written, this article does a poor job explaining how exactly serving static files locks the thread that processes the event loop. Is it assuming you (or Express's middleware) are reading the files synchronously?

# ? Feb 17, 2017 23:02

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.

ROFLburger posted:

Besides being poorly written, this article does a poor job explaining how exactly serving static files locks the thread that processes the event loop. Is it assuming you (or Express's middleware) are reading the files synchronously?

the article is terrible. one of the selling points of node.js is that it's supposed to be good at serving a high number of requests that don't use a lot of cpu, and using asynchronous IO instead of threads to read files is supposed to be like, beneficial and poo poo. then you read more and people are like "don't use it to serve static files, it's not as good as etc. etc." it's a bunch of bs.

# ? Feb 18, 2017 03:40

peepsalot: Apr 24, 2007; ��PEEP THIS...
��BITCH!

Skandranon posted:

You will likely run into issues if you try updating the DOM every 0.31ms. If you need that data at that granularity, I'd do batch updates via websocket every few 100ms, and do DOM updates then. Also, watch out for running out of memory. Chromes V8 engine can only allocate ~1.5gb of memory to a single tab before making GBS threads itself.

OK, I never asked how to display changes at 3200FPS, because that would be the dumbest and most impractical implementation possible.

I'm asking only about the mechanism of data transfer, from server to client.
I'm looking into websockets, right now I'm confused that there seems to be two different ways to send over WebSocket: Blob or ArrayBuffer? But you have to read both via a DataView anyways, or something? When would you choose one over the other?

# ? Feb 18, 2017 17:35

NoDamage: Dec 2, 2000

What lightbox/slideshow/photo gallery library is everyone using these days? Preferably mobile-friendly with a license that permits redistribution.

# ? Feb 23, 2017 11:51

Roadie: Jun 30, 2013

peepsalot posted:

I'm looking into websockets, right now I'm confused that there seems to be two different ways to send over WebSocket: Blob or ArrayBuffer? But you have to read both via a DataView anyways, or something? When would you choose one over the other?

Blobs are immutable, can have MIME types, and can be used as a source for URLs (image sources, file downloads, etc). ArrayBuffers are basically an array of ints that can be monkeyed with using appropriate TypedArrays or DataViews (usually using uint8 to access as an array of 8-bit bytes).

For most purposes you'll want to use ArrayBuffers internally (possibly with a helper lib like feross/buffer), and generate a Blob from that if you're specifically doing a file download thing or whatever at some point.

Roadie fucked around with this message at 01:59 on Feb 24, 2017

# ? Feb 23, 2017 19:57

Xom: Sep 2, 2008; 文化英雄; Fan of Britches

I'm writing a library function that changes the src of a <img> and does something when it loads. I'm looking at http://stackoverflow.com/a/2342181 and worrying about the possibility of the previous src finishing loading at just the right moment to trigger my new handler. Is that possible? If so what should I do?

edit: Screw it, I'll just poll img.complete instead.

Xom fucked around with this message at 01:01 on Feb 27, 2017

# ? Feb 26, 2017 23:52

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Xom posted:

I'm writing a library function that changes the src of a <img> and does something when it loads. I'm looking at http://stackoverflow.com/a/2342181 and worrying about the possibility of the previous src finishing loading at just the right moment to trigger my new handler. Is that possible? If so what should I do?

edit: Screw it, I'll just poll img.complete instead.

what exactly are you trying to do? you can just script it to not trigger if something is already triggering it by using a variable as a flag/lock.

# ? Feb 27, 2017 03:50

Xom: Sep 2, 2008; 文化英雄; Fan of Britches

I'm working on http://www.cardery.org/ which uses dom-to-image to convert DOM elements to PNG. Something about the way dom-to-image inlines images causes Firefox to blank out images from file:///. If I reimplement this step myself, then Firefox lets the file:/// images through if they're in the same folder. (Chrome doesn't let them through in any case.) But if I don't wait for a tiny moment before continuing on to invoking dom-to-image, then the output still has blanks where the images were. If I do wait for a moment, such as by using lodash.defer, then I mostly don't get blanked. Naturally I would like to wait for as few milliseconds as I can get away with.

What I'm imagining, though I'm not familiar enough with web development to know for sure if it is possible, is that I set the handler, then <img src="Sigmund.png"> finishes loading, then I set the src to data:bLaHbLaHbLaH, then from the trigger from the original Sigmund.png tells me to continue on to invoke dom-to-image, even though it was the dataUrl that I intended to listen for. Admittedly, my concern here is somewhat academic, given that _.defer is enough of a wait most of the time.

# ? Feb 27, 2017 04:54

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Xom posted:

I'm working on http://www.cardery.org/ which uses dom-to-image to convert DOM elements to PNG. Something about the way dom-to-image inlines images causes Firefox to blank out images from file:///. If I reimplement this step myself, then Firefox lets the file:/// images through if they're in the same folder. (Chrome doesn't let them through in any case.) But if I don't wait for a tiny moment before continuing on to invoking dom-to-image, then the output still has blanks where the images were. If I do wait for a moment, such as by using lodash.defer, then I mostly don't get blanked. Naturally I would like to wait for as few milliseconds as I can get away with.

What I'm imagining, though I'm not familiar enough with web development to know for sure if it is possible, is that I set the handler, then <img src="Sigmund.png"> finishes loading, then I set the src to data:bLaHbLaHbLaH, then from the trigger from the original Sigmund.png tells me to continue on to invoke dom-to-image, even though it was the dataUrl that I intended to listen for. Admittedly, my concern here is somewhat academic, given that _.defer is enough of a wait most of the time.

Could you simply have a 2nd image tag that is invisible? This would allow you to keep your handlers separate.

# ? Feb 27, 2017 06:34

Roadie: Jun 30, 2013

Xom posted:

I'm working on http://www.cardery.org/ which uses dom-to-image to convert DOM elements to PNG. Something about the way dom-to-image inlines images causes Firefox to blank out images from file:///. If I reimplement this step myself, then Firefox lets the file:/// images through if they're in the same folder. (Chrome doesn't let them through in any case.) But if I don't wait for a tiny moment before continuing on to invoking dom-to-image, then the output still has blanks where the images were. If I do wait for a moment, such as by using lodash.defer, then I mostly don't get blanked. Naturally I would like to wait for as few milliseconds as I can get away with.

What I'm imagining, though I'm not familiar enough with web development to know for sure if it is possible, is that I set the handler, then <img src="Sigmund.png"> finishes loading, then I set the src to data:bLaHbLaHbLaH, then from the trigger from the original Sigmund.png tells me to continue on to invoke dom-to-image, even though it was the dataUrl that I intended to listen for. Admittedly, my concern here is somewhat academic, given that _.defer is enough of a wait most of the time.

What I don't really get is why you're jiggering around in-place with stuff that's in the visible output of the page. Even if dom-to-image requires a visible element, you could use "workspace" stuff positioned outside the viewport (e.g. position: absolute; left: -10000px type wrapper), append a new node for each conversion, and delete that specific node and add the result to the visible viewport in the result callback.

Edit: Wait, maybe now I think I get what you mean. Why make the image tags like that and then alter them after they're already in place? I don't really get why it's file source to data source, instead of waiting, generating a new Image() when you have the data URL, and adding that to the right node.

Roadie fucked around with this message at 07:02 on Feb 27, 2017

# ? Feb 27, 2017 06:59

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Roadie posted:

What I don't really get is why you're jiggering around in-place with stuff that's in the visible output of the page. Even if dom-to-image requires a visible element, you could use "workspace" stuff positioned outside the viewport (e.g. position: absolute; left: -10000px type wrapper), append a new node for each conversion, and delete that specific node and add the result to the visible viewport in the result callback.

Edit: Wait, maybe now I think I get what you mean. Why make the image tags like that and then alter them after they're already in place? I don't really get why it's file source to data source, instead of waiting, generating a new Image() when you have the data URL, and adding that to the right node.

dom-to-image uses an SVG feature that allows you to embed HTML into an SVG and I'm guessing there are protections around using that to hide access to file:// URLs. Sounds like a way around that is to replace every file:// URL with a data: URL with the same content before trying to make the SVG turduckin.

I've done a thing that waited for a bunch of images to load before and IIRC, I put a handler on all of their onload events and counted the handlers as they were created. Then each handler decremented the counter until it was zero which allowed the last one to run a callback, which would make the dom-to-image call in this case. Pretty sure the modern way would be to wrap all of that in a promise.

# ? Feb 27, 2017 17:12

Roadie: Jun 30, 2013

Munkeymon posted:

dom-to-image uses an SVG feature that allows you to embed HTML into an SVG and I'm guessing there are protections around using that to hide access to file:// URLs. Sounds like a way around that is to replace every file:// URL with a data: URL with the same content before trying to make the SVG turduckin.

I've done a thing that waited for a bunch of images to load before and IIRC, I put a handler on all of their onload events and counted the handlers as they were created. Then each handler decremented the counter until it was zero which allowed the last one to run a callback, which would make the dom-to-image call in this case. Pretty sure the modern way would be to wrap all of that in a promise.

Right. What I mean is (now that I've got my head more wrapped around it), it'd be better to do that file url to data url step before even creating the DOM nodes that get run through dom-to-image.

code:

function createCardImage (fileUrl) {
    return new Promise(fileUrl => {
        // ... do conversion stuff
        resolve("data url here")
    }).then(dataUrl => {
        // ... create node
        resolve("node id here")
    }).then(nodeId => {
        // ... do dom-to-image stuff here
        resolve("image result here")
    })
}

createCardImage("whatever").then(imageResult => {
    // add image to visible page here
})

Roadie fucked around with this message at 19:46 on Feb 27, 2017

# ? Feb 27, 2017 19:27

Xom: Sep 2, 2008; 文化英雄; Fan of Britches

Turns out dom-to-image already does element.onload = resolve; element.src = dataUrl, which implies onload doesn't necessarily avert my problem. I don't feel like investigating, so I'll take my chances with setTimeout.

I don't want to bother the user about dataUrls. I can handle it in the library. The user shouldn't have to do anything special.

# ? Mar 1, 2017 06:39

MrMoo: Sep 14, 2000

What does Google docs use for screenshots in the help system, is it something like dom-to-image?

# ? Mar 1, 2017 16:27

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

MrMoo posted:

What does Google docs use for screenshots in the help system, is it something like dom-to-image?

They wrote a mostly-complete DOM to canvas renderer in JS, if it's the reporting system I remember reading about.

# ? Mar 1, 2017 17:42

Xom: Sep 2, 2008; 文化英雄; Fan of Britches

Is there a way to display an image at its actual resolution, ignoring the user's OS zoom and/or browser zoom, showing one image pixel per monitor pixel?

# ? Mar 1, 2017 17:58

biznatchio: Mar 31, 2001; Buglord

Xom posted:

Is there a way to display an image at its actual resolution, ignoring the user's OS zoom and/or browser zoom, showing one image pixel per monitor pixel?

window.devicePixelRatio will give you the ratio of device pixels to CSS pixels. If you use that to scale the image's size, you can make it map image pixels directly to monitor pixels. Careful though, as the documentation mentions, this value can change (i.e., if the user moves the window between monitors of different DPI levels), and there's no event to tell you the value has changed.

# ? Mar 1, 2017 22:34

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.

biznatchio posted:

window.devicePixelRatio will give you the ratio of device pixels to CSS pixels. If you use that to scale the image's size, you can make it map image pixels directly to monitor pixels. Careful though, as the documentation mentions, this value can change (i.e., if the user moves the window between monitors of different DPI levels), and there's no event to tell you the value has changed.

Yeah, but the output image will still be scaled and have scaling artifacts unfortunately. It comes pretty close.

# ? Mar 2, 2017 02:00

biznatchio: Mar 31, 2001; Buglord

Bruegels Fuckbooks posted:

Yeah, but the output image will still be scaled and have scaling artifacts unfortunately. It comes pretty close.

Not in my experience on desktop Google Chrome on a high DPI screen. I can't vouch for other browsers, but in that setup, if you use the devicePixelRatio to scale an image's size down via CSS to the proper screen size, it will display properly imagepixel-to-monitorpixel.

Example:

Raw Image:

Chrome on a High DPI display -- top image is a raw <img> element, bottom image sets CSS to the image's naturalWidth and naturalHeight divided by window.devicePixelRatio:

The scaled image is pixel perfect.

After zooming the browser to 110% and reloading, to make sure the devicePixelRatio wasn't a whole number:

The scaled image is still pixel perfect.

Code below:

code:

    <body>

        <div>Device Pixel Ratio: <span id="spnPixelRatio"></span>.
        <br>
        <br>
        Raw image: <img src="image.gif"/>
        <br>
        <br>
        Scaled image: <img src="image.gif" id="imgScaled"/>


        <script type="text/javascript">

        window.addEventListener("load", function () {
            var dpc = window.devicePixelRatio;

            document.getElementById("spnPixelRatio").innerText = dpc;

            var imgScaled = document.getElementById("imgScaled");
            imgScaled.style.width = (+imgScaled.naturalWidth / dpc) + "px";
            imgScaled.style.height = (+imgScaled.naturalHeight / dpc) + "px";
        });

        </script>
    </body>

edit: Also tried resizing by setting CSS zoom instead of width/height, the result also came out pixel perfect. Code:

code:

imgScaled.style.zoom = ((1 / dpc)*100) + "%";

biznatchio fucked around with this message at 11:23 on Mar 2, 2017

# ? Mar 2, 2017 11:06

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.

biznatchio posted:

Not in my experience on desktop Google Chrome on a high DPI screen. I can't vouch for other browsers, but in that setup, if you use the devicePixelRatio to scale an image's size down via CSS to the proper screen size, it will display properly imagepixel-to-monitorpixel.

Example:

Raw Image:

Chrome on a High DPI display -- top image is a raw <img> element, bottom image sets CSS to the image's naturalWidth and naturalHeight divided by window.devicePixelRatio:

The scaled image is pixel perfect.

After zooming the browser to 110% and reloading, to make sure the devicePixelRatio wasn't a whole number:

The scaled image is still pixel perfect.

Code below:
code:
    <body>

        <div>Device Pixel Ratio: <span id="spnPixelRatio"></span>.
        <br>
        <br>
        Raw image: <img src="image.gif"/>
        <br>
        <br>
        Scaled image: <img src="image.gif" id="imgScaled"/>


        <script type="text/javascript">

        window.addEventListener("load", function () {
            var dpc = window.devicePixelRatio;

            document.getElementById("spnPixelRatio").innerText = dpc;

            var imgScaled = document.getElementById("imgScaled");
            imgScaled.style.width = (+imgScaled.naturalWidth / dpc) + "px";
            imgScaled.style.height = (+imgScaled.naturalHeight / dpc) + "px";
        });

        </script>
    </body>
edit: Also tried resizing by setting CSS zoom instead of width/height, the result also came out pixel perfect. Code:
code:
imgScaled.style.zoom = ((1 / dpc)*100) + "%";

Let me mess with this today at work. There were three things I did that were different:
1. I used Chrome in high DPI mode.
2. Using PNG (smpte as the test pattern) instead of JPEG.
3. Using HTML5 canvas drawImage call.

# ? Mar 2, 2017 13:20

biznatchio: Mar 31, 2001; Buglord

Canvas was where I originally noticed the behavior, actually. If the width and height attributes of the canvas are scaled by devicePixelRatio with respect to the element's DOM width and height, it'll also display pixel perfect.

# ? Mar 3, 2017 07:10

Fruit Smoothies: Mar 28, 2004; The bat with a ZING

This is a Vue.js framework question, so I understand this may not be the perfect thread for it. I am having issues with the scoping of slots.
Here's a simple list example. Most Vue tutorials will end up with the HTML on your main page looking like this (pre-render)

code:

	<div>
		<list-component></list-component>
	</div>

Which I absolutely despise because it gives you too little information about the construction of the list! My goal is to create

code:

	<div>
		<list-component>
			<list-item v-for:"item in items">
				{{item.name}}
			</item>
		</list-component>
	</div>

The problem here is the <slot> in list-component's template. This slot (which contains <list-item>) has NO context about the "items" data because the slot is rendered outside the parent's scope. There is documentation on this phenomenon here but it's not especially clear documentation!

Before I give up and conform to the ridiculously vague top example, can anyone offer any help here?

# ? Mar 3, 2017 16:42

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 14:05

I'm Crap: Aug 15, 2001

Has anyone here ever used Collections.js, and can you explain why it's shrieking at me? I specifically gave it an equals function and a comparator function, so I don't know why it's complaining about things being "incomparable". It works fine if I give it an array of objects with only the 'v' property and "null" as an equals function, or an array where only one object has 'a' set. Maybe I'm overlooking something really stupid.

code:

var SortedSet, objs, set;
SortedSet = require('collections/sorted-set');
objs = [
  {v: 90, a: 'a'},
  {v: 1, a: 'b'},
  {v: 4, a: 'c'},
  {v: 2, a: 'd'},
  {v: 6, a: 'e'}, 
  {v: 1, a: 'f'}, 
  {v: 2343, a: 'g'},
  {v: 34, a: 'h'}
];
set = new SortedSet(objs, function(x, y){
  return x.a === y.a;
}, function(x, y){
  return x.v - y.v;
});

code:

Error: SortedSet cannot contain incomparable but inequal values: [object Object] and [object Object]
    at SortedSet.add (path-to\node_modules\collections\sorted-set.js:77:23)
    at SortedSet.GenericCollection.addEach (path-to\node_modules\collections\generic-collection.js:17:18)
    at new SortedSet (path-to\node_modules\collections\sorted-set.js:21:10)
    at Object.<anonymous> (path-to\this-script.js:31:7)
27|     v: 34,
28|     a: 'h'
29|   }
30| ];
31+ set = new SortedSet(objs, function(x, y){
32|   return x.a === y.a;
33| }, function(x, y){
34|   return x.v - y.v;
35| });

Failing that, does anyone know any JavaScript data structure libraries that are as fully featured as Collections.js, but actually work? Buckets seems okay from what I've seen of it (this example works in Buckets) but its APIs are pretty bare-bones.

# ? Mar 4, 2017 16:42

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

«‹›277 »