Skip to content
This repository has been archived by the owner on Jun 12, 2018. It is now read-only.

Home

Jump to bottom
Joseph Silvestre edited this page Mar 18, 2015 · 1 revision

This presents the client's architecture, and the interactions between the modules.

It is quite complex because there are many cases to handle: conflict, cancel upload, errors, multiple uploads, how an upload is reflected across various clients, or broken binary detection.

Non-Backbone-standard interactions are explicits thanks to methods with coherent names.

  • baseCollection: this is the collection with all models (File and Folder) that are loaded when the user browses.

  • folder view: what is displayed to the user is basically a sub collection of the base collection (a folder). This sub collection is a Backbone.Projection.

  • upload queue: the upload queue is an async.queue which handles uploads 5 by 5. It needs to know which models are in "upload state" mainly to output a feedback at the end of the upload. For that purpose, it used another Backbone.Projection, that the files collection handles. There are multiple states for a model during the upload process. States can be separate in two parts: local state and shared state.

  • Local state is maintained by the client performing the upload

  • Shared state is maintained across ALL clients through web sockets. The local states and shared states are explicitely and broadly documented within models/file. Shared state is needed so that when you upload a file, other clients see it and don't think it's broken (if it doesn't have its binary yet for instance).

Local state is needed to handle everything else: conflict, success, errors, ... The local state is a model's property rather than an actual Backbone.Model attribute, to prevent it from being sent to the server.

Those states must be changed and accessed through the getters and setters declared in models/file.

Once you understand how flows the data when it's added to the upload queue (by either addBlobs or addFolderBlobs), it's just a matter of understanding local state and shared state to display what you want within the view.

This architecture also means that whenever there is a bug in a feature, that can mean two things:

  • the local state has been changed in a way it should not have been.
  • the view doesn't handle properly the states. It's still complex because there are many cases to test and check whenever you change the upload queue code (or related code such as conflict management in views/folder). There is no magical solution to handle the complexity, so we put effort into "hiding" the complexity behind a coherent API.
Clone this wiki locally