Add possibility to have more than one time domains #301
Comments
evancharlton
pushed a commit
that referenced
this issue
May 30, 2019
Clean up the internal data flow inside of the Scaler component. This
refactoring had a few main goals:
1. Fully-own the responsibility of providing scaled data downstream
alongside the Series and Collection items.
2. Increase performance by using better checks to detect when the
incoming Series and Collections objects were externally changed.
3. Stop exposing domainsByItemId / subDomainsByItemId to the
downstream rendering components, in deference to Series and
Collection objects directly.
4. Get closer toward enabling per-Series timeDomains / timeSubDomains
as documented in #301.
The end result of this is that the (internal) API has nontrivially
changed. Instead of Scaler exposing maps of domainsByItemId and
subDomainByItemId, it will simply pass through the series and
collections arrays, but they are now all guaranteed to be
fully-populated with domain and subDomain information. This means that
rendering components can simply render using the timeDomain,
timeSubDomain, xDomain, xSubDomain, yDomain, and ySubDomain domains
(which are guaranteed to be present) and don't need to concern
themselves with how they were populated (user/state, props, calculated
from data, or placeholders).
This does not yet fully enable separate timeDomain / timeSubdomain
throughout the library, but it removes almost all blockers. The final
piece to this puzzle is in DataProvider -- it needs to learn a one more
trick in order to support this (it currently only knows about one
timeSubDomain). That cleanup will be saved for a future PR.
evancharlton
pushed a commit
that referenced
this issue
May 30, 2019
Clean up the internal data flow inside of the Scaler component. This
refactoring had a few main goals:
1. Fully-own the responsibility of providing scaled data downstream
alongside the Series and Collection items.
2. Increase performance by using better checks to detect when the
incoming Series and Collections objects were externally changed.
3. Stop exposing domainsByItemId / subDomainsByItemId to the
downstream rendering components, in deference to Series and
Collection objects directly.
4. Get closer toward enabling per-Series timeDomains / timeSubDomains
as documented in #301.
The end result of this is that the (internal) API has nontrivially
changed. Instead of Scaler exposing maps of domainsByItemId and
subDomainByItemId, it will simply pass through the series and
collections arrays, but they are now all guaranteed to be
fully-populated with domain and subDomain information. This means that
rendering components can simply render using the timeDomain,
timeSubDomain, xDomain, xSubDomain, yDomain, and ySubDomain domains
(which are guaranteed to be present) and don't need to concern
themselves with how they were populated (user/state, props, calculated
from data, or placeholders).
This does not yet fully enable separate timeDomain / timeSubdomain
throughout the library, but it removes almost all blockers. The final
piece to this puzzle is in DataProvider -- it needs to learn a one more
trick in order to support this (it currently only knows about one
timeSubDomain). That cleanup will be saved for a future PR.
evancharlton
pushed a commit
that referenced
this issue
Jul 15, 2019
Clean up the internal data flow inside of the Scaler component. This
refactoring had a few main goals:
1. Fully-own the responsibility of providing scaled data downstream
alongside the Series and Collection items.
2. Increase performance by using better checks to detect when the
incoming Series and Collections objects were externally changed.
3. Stop exposing domainsByItemId / subDomainsByItemId to the
downstream rendering components, in deference to Series and
Collection objects directly.
4. Get closer toward enabling per-Series timeDomains / timeSubDomains
as documented in #301.
The end result of this is that the (internal) API has nontrivially
changed. Instead of Scaler exposing maps of domainsByItemId and
subDomainByItemId, it will simply pass through the series and
collections arrays, but they are now all guaranteed to be
fully-populated with domain and subDomain information. This means that
rendering components can simply render using the timeDomain,
timeSubDomain, xDomain, xSubDomain, yDomain, and ySubDomain domains
(which are guaranteed to be present) and don't need to concern
themselves with how they were populated (user/state, props, calculated
from data, or placeholders).
This does not yet fully enable separate timeDomain / timeSubdomain
throughout the library, but it removes almost all blockers. The final
piece to this puzzle is in DataProvider -- it needs to learn a one more
trick in order to support this (it currently only knows about one
timeSubDomain). That cleanup will be saved for a future PR.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: