Create a gist now

Instantly share code, notes, and snippets.

Data Access in YUI

Data Access in YUI

Problem Statement

Data access in YUI is fragmented and diverging, and is lacking a normalization layer to which Widget and application developers can develop and rely on.

Proposed Solution

Implement a layered approach where each layer adds higher-level concepts, normalizing to the layer below it:

  1. Super light-weight transport base-modules which are simply a static function that performs the work (and probably calls a callback function).

  2. A Transaction factory for each transport which returns an instance of a generic Transaction class. These factory functions would be provided in a separate module that would require the transport base-module they are providing transaction support for. The Transaction instances would provide events scoped to the specific transaction.

  3. DataSource would add instantiability around each of the transports allowing for a modeling of external/remote resource. DataSource instances would retain configuration between requests and use that configuration as the defaults for each request; i.e. a DataSource instance would be used to make repeated calls to the same resource endpoint.


  • [Stakeholders] What do we think of the intended direction of the architecture for transport layering up to DataSource as the instantiable thing?

  • [Thomas] We feel JSONP and YQL are not structured in a way that migrates cleanly to that goal. What do you think would be the best idea for IO? To remove instantiability, copy the existing bad implementations, or something else?

  • [Ryan] You have specific goals for Get in 3.5.0. How would those plans be impacted by the proposed architecture?

Short-Term Roadmap

  • Investigate what changes (if any) we can make to JSONP, YQL, Get, and IO to unify their approaches and align them with the future goals.

  • Deprecate instantiability of JSONP, YQL, and IO for 3.5.0 (before implementers get too invested in the new featureset). This would bring IO, JSON, and YQL more inline and decrease k-weight.

  • Remove event facade from io-base; separate transport from the evented transaction layer. This should also remove k-weight and offer a high performance option for internal properties such as Mail and Front Page to use the transport API directly.

  • Investigate feasibility of abstracting request queuing, form serialization, and other IO features at the transaction factory or DataSource level. Where would file upload functionality live?

  • Shift to DataSource to act as the instantiable, normalized layer on top of transports XHR, XDR, Get, JSONP, YQL, etc. (no code change required for immediate support).

Short-Term Benefits

  • Reduced k-weight to io-base, jsonp, and yql.

  • Normalized API to implementers, while transports layers are allowed to be different, since they are different mechanisms under the hood.

  • Full support for instantiability and event-facade bubbling via DataSource.

  • Simpler and more extensible architecture to support the layered approach.

  • Improved learnability.

Longer-Term Roadmap

  • Create a generic Transaction class which is augmented with EventTarget and provides the transaction-level events. This would allow each transport to return an instance of the same Transaction object, and also enables support for deferreds/promises.

  • Layer on the transaction support on top of the lower-level transports via a static factory method for each transport. This would be supplied in a separate module from the core transport functionality and would add the transaction-level event support through the use of a generic Transaction class instances.

  • DataSource factory method to switch transport types depending on configuration. (Then we can remove duplicate code in autocomplete-base.)

  • DataSource would also return these same Transaction objects, but also allow for DataSchema support.

  • Support additional transports like websockets, postMessage, others?

  • YQL and JSONP should follow this new pattern.

Known Issues

  • JSONP and YQL incorrectly model a request.

  • Transaction-level events and event bubbling don't play well together in IO.

  • autocomplete-sources ought not to exist, DataSource should be doing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment