It’s a very weird way of doing things.

The result with this strategy is that you may need the companyName and end-up at some point with code that does back:

companyName = pageTitle

or worse:

companyName = pageTitle.split(‘ - ‘)[0]

Because there is a moment when you will need to get the companyName again for some comparison or something whatever logic (e.g. is selected account profile current company ?)

This feels very confusing.

Instead pass companyName and keep it that way until the very last moment that you display it on the page (e.g. when rendering the view/template)

The whole point is that when you need companyName for another thing, you should create a parameter `anotherThing` and backend will set companyName into it as well. It's designed to make it very weird to _not_ do that, so that you don't do that.

firstDivOnThePageBeforeMainMenuBlock ?

Like most things, it depends. If you have a generic math module, you of course want generic parameter names. It would be weird to have a differential math library with a bunch of random terminology from another domain mixed in.

If the page only makes sense if a company name is used as a title, then of course use companyName as the variable.

They're suggesting using the pageTitle parameter for the title, and being explicit about how things are used. If you pass a companyName parameter, it is quite generic. You just happen to use the companyName for the title, but you also use it elsewhere. Someone might want to add some additional info to the title. Their solution will likely be a new parameter and then concatenate these values together. But if you just thought about being explicit to begin with, then you'd already have the functionality to do that.

The idea is to write things as standalone components. Which is a pretty universal programming strategy.

You guys are each partially right. What you need is MIDDLEWARE.

On the one hand, you have some data coming in format X.

On the other hand, you need the data in format Y.

What you need is to define how to map X to Y. And then when you request Y, a way to indicate what parts of X you really need, so the code getting X can optimize, if it needs.

In my experience, the real issue is how to cache the X - should we be caching all of it depending on the Y, or should we be caching parts and understanding how they fit together. I have had problems with updating caches, and I am looking for solutions!

https://news.ycombinator.com/item?id=36146520

I think what you are looking for a is "(pure) functional reactive programming".

The problem with caching is that it is very often highly individual and it usually comes with drawbacks, i.e. you win performance here but lose it there or you win performance but you lose consistency. (related: CAP theorem)

So I doubt there is any "generic" solution that will or even could make you happy. But if you find one, let me know. :-)

Well, in a single-threadsd environment you almost can have consistency, and you can cache the latest results. What I am saying is that if a result consists of X1, X2, X3 but you don’t need all of them for a certain request, then you wind up caching X1, X2 one time, and requesting X1, X3 another time, what to do with the cache of (X1, X2)? Currently I just update the caches which are subsets (X1) of a cached response, and do it with manual individual code. I hoped that I could have some sort of dependency graph. Maybe reactive programming, yeah. But that would essentially be some sort of declarative language, to run pure functions which still have custom code. Hmm

Single threaded just means there is no parallelization, but there can (and usually is) still concurrency, which is what reactive programming is about.

I think reactive programing solves the "dependency graph" problem to you in the sense that you just have to "change" one value and then all dependencies (and their dependencies) update. You still have to define the relations though.