Frontend refactoring: model with refs vs full structures

[ymajoros]

Would it be better to have Ws* objects with refs, that are converted (via converters) to full structures, just as in backend? Would it take long?

Please estimate before doing it.

[cghislai]

I was doing something similar. With the refactor changes I pushed it is getting a bit closer. there are a few Local* classes with (some) *Refs fetched to full structure. There are also extra fields.

It is not as easy as we have to keep references to requests since we don't want an old request to override contents of a newer one. Also, the full structure that would be fetched might depend on the context.

With all this ajax stuff, I tried to fetch as few content as possible while keeping things as simple as possible. All of this is handled by services, and it is transparent to the controllers and the views.

[ymajoros]

Can you elaborate on that? Which structure could overwrite which?

e.g. PUT as many ItemSales as you want and have blocking (synchronized) GETs for Sale to get the total. Is this possible?

[cghislai]

Currently, the service rebuilds the sale structure using cascading requests or parallel request if its feasible.

• It keeps reference of requests, and dismiss those that are not meaningful anymore. Pushing lots of itemSale will generate lots of GET totalPaid requests, but only the last one will not be dismissed.
• It only fetches information useful in its context.

So, it is quite working as you describe currently.

I was thinking that if all of this was automated; refreshing a sale would generate a lot of requests: GET /sale POST /itemSale/search to get the list of items GET /itemVariant for each itemSale GET /picture for each itemVariant POST /accountingEntry/search to get the list of accounting entries GET /account/ to get account name & desc GET /sale/payed to get paid amount ... Which is for most case more than necessary.

[cghislai]

I've been thinking about this, to have something more automated. I though of an optional-like interface, something like

class Optional<T> {
  ref: WithId;
  value: T;
  reqeust: Request;
}

so that we can store reference, fetch the object if required, and track request in case it needs to be dismissed. I made an attempt at implementing that, but its a pain - everything needs to be rewritten, and I did not feel like it was the right way neither.

Do you still have something on your mind concerning this issue?

[ymajoros]

I think it's easier than that.

Just have an ItemConverter, which has an id/item dictionary (or hashmap or associative array, whatever it's called in js).

When fetching objects, convert them using ItemConverter. As js is "dynamic" (sigh), remove the reference and replace it with cached item. If there is no item yet, get it. Dictionary entries can be removed: ItemConverter::clean(itemRef) or ItemConverter::cleanAll().

Is that ok?

Le lun. 7 sept. 2015 à 13:25, cghislai notifications@github.com a écrit :

I've been thinking about this, to have something more automated. I though of an optional-like interface, something like

class Optional { ref: WithId; value: T; reqeust: Request; }

so that we can store reference, fetch the object if required, and track request in case it needs to be dismissed. I made an attempt at implementing that, but its a pain - everything needs to be rewritten, and I did not feel like it was the right way neither.

Do you still have something on your mind concerning this issue?

— Reply to this email directly or view it on GitHub https://github.com/Valuya/comptoir/issues/60#issuecomment-138274429.

Yannick Majoros Valuya sprl

[cghislai]

Yep it sounds good.

[cghislai]

pushed