Page MenuHomePhabricator

Getting rid of wikibase.fetchedEntities (global front-end data store) and its usage in jQuery.wikibase.***view widgets
Closed, ResolvedPublic

Description

Ever since we started with the "new UI", so basically the jQuery.wikibase.***view widgets, we have been using wikibase.fetchedEntities as a global front-end data store. This store is being accessed in the view widgets. It is just a plain object where each field key is an entity ID and the content is a "wikibase.store.FetchedContent" object holding an "wikibase.Entity" instance as its content.

In case of the php EntityView and on certain special pages (e.g. SimpleQuery special page) the backend is generating a serialized, "basic" version of all used entities and puts that serialized form into the mw.config var "wbUsedEntities". In the front-end code initializing the respective view, the "wbUsedEntities" is being deserialized and put into wikibase.fetchedEntities.
In some cases, e.g. creating a new claim via the claimview widget, the widget will receive information about the entities used in the new claim (e.g. main snak's property) and add it to wikibase.fetchedEntities.

Instead of having this "global store", we should just inject some proper store instance into the widgets. There should be a proper interface for the store and different implementations. When requesting data from the store, a promise should be returned to support asynchronous store implementations.


Version: unspecified
Severity: normal
Whiteboard: u=dev c=frontend p=5

Details

Reference
bz54082

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:12 AM
bzimport set Reference to bz54082.
bzimport added a subscriber: Unknown Object (MLST).

Also see the Quafoo code review report, section 6.2.12 "Avoiding 'global' Data Stores". This has been one point addressed before the code review, the suggested approach is pretty much what we had in our inline TODOs.
Also consider this as part of switching to a proper MVC or MVVM architecture.

Getting this done should also result into getting rid of yet another global evilness, wikibase.getRevisionStore()

wikibase.getRevisionStore() though is also used by the "old UI".

Maybe this should be done only with the planned rewrite of the front end. There seems little advantage in doing this in the old UI, and then rewriting it.

This is not a problem of the "old ui", this concerns the "new ui".
I don't think we have decided upon a rewrite of jQuery.wikibase ui yet, declaring the "new ui" to be "old ui" as well (confusing..., lets refer to the new ui as jQuery.wikibase ui?)

(In reply to comment #2)

Getting this done should also result into getting rid of yet another global
evilness, wikibase.getRevisionStore()

wikibase.getRevisionStore() though is also used by the "old UI".

Actually, this is not true, this would be the case when solving Bug 56246.

In any case, this bug is much more trivial than Bug 56246 and should not be confused with that one. This bug is solely about store lookups for entity information within ***view widgets while Bug 56246 is more about how to sync the model with the view.

Change 107554 had a related patch set uploaded by Adrian Lang:
Replace wb.fetchedEntities with wb.store.EntityStore

https://gerrit.wikimedia.org/r/107554

Change 107554 merged by jenkins-bot:
Replace wb.fetchedEntities with wb.store.EntityStore

https://gerrit.wikimedia.org/r/107554