You can pass objects by reference. That's the closest thing to a pointer you can get in Javascript. If you really need to handle pointers directly though, you probably shouldn't be using a highly abstracted scripting language like Javascript and might want to look into using a compiled programming language like C/C++ or Rust.

>>3444
Caching idea would be best done with a dictionary hashes going to pointers. The best alternative I can think of is associating ids to hashes and hashes to ids, but waste. At the point where it gets too complicated I think the only node solution is a Redis in memory database. In the least this allows you to go horizontal with it's master slave database thingy

>>3446
>is associating ids to hashes and hashes to ids
is associating ids to hashes and ids to caches

What are you trying to accomplish? What are the hashes for?

>>3449
prevent redundancy when storing data

---

opts = {noimage:true, notext:false, somethingirrelevant:true};
optshash_1 = hash(opts);
console.log(optshash_1);
// "101"
value_1 = "<p>asdf</p>"; // a very large string

opts = {noimage:true, notext:false, somethingirrelevant:false};
optshash_2 = hash(opts);
console.log(optshash_2);
// "100"
value_2 = "<p>asdf</p>"; // a very large identical string

store.push({optshash_2:value_2});
store.push({optshash_1:value_1});

// values 2 and 1 are identical yet taking up two memory spaces.
// if two clients have different options and are trying to get the same data this is a waste
// The alternative prevents redundant information

index_store.push({optshash_1:0});
index_store.push({optshash_2:0});
store = [value_1];

>index_store.push({optshash_1:0});
>index_store.push({optshash_2:0});
index_store[optshash_1] = 0;
index_store[optshash_2] = 0;
because then it's a dict, which was what I was aiming for

>>3450
How does the software know the strings are identical? Is there a comparison at some point?

nerds will get swirlies

>>3452
The options are the decider for what you get. no Comparision, it's a hash table.


//setting the store

var index_store = {};
var store = [];

function hash(opts){
return "" + (opts.noimage ? 1 : 0) + (opts.notext ? 1 : 0) + (opts.somethingirrelevan ? 1 : 0);
}

function storeValue(optshash, value){
index_store[optshash] = store.length;
store.push(value);
}


var opts_1 = hash({noimage:true, notext:false, somethingirrelevant:true});
var value_1 = "asdf";
storeValue(opts_1 , value_1);

var opts_2 = hash({noimage:true, notext:false, somethingirrelevant:false});
var value_2 = "asdf";
storeValue(opts_2 , value_2);


// later evaluation
var opts_1 = hash({noimage:true, notext:false, somethingirrelevant:true});
function getIfCached(opts){
if(index_store[opts])
return store[index_store[opts]];
}

var opts_3 = hash({noimage:false, notext:false, somethingirrelevant:true});

console.log(getIfCached(opts_1));
//asdf
console.log(getIfCached(opts_2));
//asdf
console.log(getIfCached(opts_3));
//undefined

>>3453
rude!

It's procedural generation of items with a hash table which stores the end result of decisions. The options are the seeds which decide the outcome.

oh shoot, I realize a mistake

I see, you have to make a pretty serious string comparison to save yourself the ram..

---
//setting the store

var index_store = {};
var store = [];

function hash(opts){
return "" + (opts.noimage ? 1 : 0) + (opts.notext ? 1 : 0) + (opts.somethingirrelevant? 1 : 0);
}

function storeValue(optshash, value){
var cont = true;
for (var i = 0 ; i < store.length ; i++){
if(value == store[i]) {
cont = false;
break;
}
}
if(cont)
store.push(value);
index_store[optshash] = store.length - 1;
}


var opts_1 = hash({noimage:true, notext:false, somethingirrelevant:true});
var value_1 = "asdf";
storeValue(opts_1 , value_1);

var opts_2 = hash({noimage:true, notext:false, somethingirrelevant:false});
var value_2 = "asdf";
storeValue(opts_2 , value_2);

console.log(store.length);
// 1

// later evaluation
var opts_1 = hash({noimage:true, notext:false, somethingirrelevant:true});
function getIfCached(opts){
if(index_store[opts] != undefined)
return store[index_store[opts]];
}

var opts_3 = hash({noimage:false, notext:false, somethingirrelevant:true});

console.log(getIfCached(opts_1));
//asdf
console.log(getIfCached(opts_2));
//asdf
console.log(getIfCached(opts_3));
//undefined

A warning: If you use the object-as-dictionary hack, you need to make that none of your keys can ever be any of the following:

"constructor"
"__proto__"
"__noSuchMethod__"
"__defineGetter__"
"__defineSetter__"
"__lookupGetter__"
"__lookupSetter__"
"hasOwnProperty"
"isPrototypeOf"
"propertyIsEnumerable"
"toLocaleString"
"toString"
"unwatch"
"valueOf"
"watch"

Or anything else that may get added to the Object prototype in the future, or by software you run. If any of these strings are used as a key, you may get unexpected behavior or even security problems. The key "__proto__" is especially dangerous. Look up "prototype pollution" for examples of the problems it's caused.

Alternatively, consider using Map.
[If you really need to use objects, Object.create(null) is a solution, but the only reasons I can think of to use that is to create objects for JSON.stringify or to security-patch existing code.]

It might be a good idea to remove any known irrelevant options before looking the string up in your cache to prevent the string from needing to be regenerated. (Or the extra code might slow things down; it's something you'd need to test.)

>>3460
Map. Sounds better than an object.
I guess I should add that data is stored as a component_string and a last_used_time. When the cache is filled it's going to boot out the oldest item. This way popular things don't get removed from a cache causing temporary slowdowns and when a googlebot crawls every page it doesn't impact viewers.

>>3461
It's crossed my mind but it's trying to predict the outcome of results when it might not always be black or white.

If you want the cache to do you any good, it's probably a good idea to minimize the number of options that can affect the HTML of a post.

>>3464
yeah, only the necessary settings are put into a cookie for rendering. I dropped a few things that I didn't think were worthwhile. The 3 cache specific variables of server rendering are embedding thumbnail vs standard embed, Reverse image included or not and post stub, missing(not included) or full post. Even then I could take out the reverse image cookie and put that in localstore. A 200mb cache can hold a lot of 1kb posts.

The other big thing is the sorting type, but posts are cached so it's just a matter of working out client and server to be consistent.

Default mode will be where posts are added as you scroll(infinite scrolling) either in the index or inside of a thread so the server won't die when it hits a 1000 post load that it may or may not have fully cached. A page won't be completely loaded unless a GET flag is set or the user sets the option to be given paged mode. The concept of pages could potentially just vanish unless an archive requests it.

and an update system is going to be another component so the main server can notify the SSR server that it needs to either adjust contents according to the given message. So things like the WiP score counter, ban messages and edits are accounted for so that the server can stay up to date with that,

>>3465
If I were expecting someone to take it to the level of a complete noscript system then someone could potentially cache it all. Every component and build it themselves.

I'd also like people to maybe prefer using a desktop application for kissu(https://www.electronjs.org/) or mobile app(https://reactnative.dev/).

So the server side rendering is only one piece of my plan here and things can be done through direct HTTP server messages.

wish I was a tech wiz

>>3476
be the change you want to see in the world