hulilabs / ju-components Goto Github PK

We currently support unified (all from resource server) and serverless srategies. There is no way to define combined strategies.

The Request Payload - or to be more precise: payload body of a HTTP Request - is the data normally send by a POST or PUT Request. It's the part after the headers and the CRLF of a HTTP Request.
Source: http://stackoverflow.com/questions/23118249/whats-the-difference-between-request-payload-vs-form-data-as-seen-in-chrome

There is several methods (getComponentPayload, getPayload, others) which were named as if they were meant to compose ajax payload data, but instead they are used for calling a proxy. Lets review some naming conventions to make those methods more significant.

Suggestion:

• Separate response, proxy and payload as handlers for all requests
• Use correct naming as "fetch" , "fetchDataFromServer"

We are aware of known issues happening because the proxy and save were attached as part of components classes hierarchy (from BaseComponent) instead of using composition

Known issues

• Landing components can't detect emptiness state
• Proxy or save can't be added to any level of the components tree, so they were always required at root component of view

Suggested solution:
Create the concept of flows which are managed by handlers. This will let us separate proxy (will be known as 'fetch-flow') and save-flow to be compose into any component class definition

As we learn from the immediate save strategy added on v.1.0.4, any strategy should support an options for customizing the changes tracker (which in the end determines the events detected as "change")

• setData does not respect data and extraParentData parameters order
• setData does not support custom params after second argument and bypass it to setChildrenData- > addChild -> ....
• Editable is not fully separated

Add a save strategy for supporting autosave on components
A custom tracker may be needed for listening custom application events

We are seeing problems on children definition assignments

this.childrenDef = CHILDREN_DEFINITION;

This is bad! :( A direct reference is stored from childrenDef to CHILDREN_DEFINITION which is then passed to binders or class methods meaning the original definition is changed directly between instances. We should provide some standard setter method (hide inner implementation) and safe assign a clone of the provided definition.

this.setChildrenDefinition(CHILDREN_DEFINITION)
setChildrenDefinition : function(childrenDef){ this.childrenDef = $.extend(true, {}, childrenDef); }

There should be a way to reuse options handling as a composition of any class

• setOptions
• optionsPrepare
• optionsCollector

Object extending and cloning are currently handle by jQuery.extend()
We should keep in mind removing jQuery dependency and avoid the ambiguous usage of $.extend

Sounds to me like a good idea to have a "Ju" global object (similar to jQuery) to easily access utilities like this.

Ju-components should not depende on external libraries as:
bower.json
"dependencies": {
....
"x-editable": "1.5.1", ---> x-editable and select2 library
"mustache.js": ">=2.2.0", -----> render engine
"dropzone": ">=4.2.0" -----> uploader
},

Ju-components doesn't currently provide a standard dynamic children loader helper. From setChildrenDefinition (v.1.0.3) and project experiences, we learn that it is very useful to have a loader which can be customize to support permissions, flag and other checks to help on initChildrenDef task.

@see base-with-children-loader

base-ui : line 368
var isLocalEmpty = self.checkLocalEmptiness(results[0]);

If a component is merged with its view on appendToView, and later it's destroyed, the whole insertion point is removed from the DOM, which may cause problems whenever it has to be re-inserted.

When a landing component is destroy, list are marked as changed by default

• LandingComponent.destroy()
• List.destroy()
• List.clear()
• List.emptyList()
• List.fireEventAndNotify(ListComponent.EV.CLEARED)
• Save-Changes > Changes-Tracker.on(ListComponent.EV.CLEARED, modifiedHandler)
• Changes-Tracker.fireEvent(ChangesTracker.EV.COMPONENT_CHANGED, changedComponent);

As root-append works on any root component when initializing, same behaviors should be work for on destroy. It should support deletion of a portion of the components tree or specific children.

Concerns:

• Memory management
• Dettach/reattach handling
• Backbone reference and listeners

Known issue:

• DOM stored data (ie jQuery.data) is deleted when calling jQuery.remove (vendor conflicts)
  Reproduce : list component > destroy > clear > child.destroy() [.remove()] > cascadeStateChange() > checkEmptiness() > getData() > vendor conflict [.data() is missing due to remove()]

In #35 a big improvement was added to the resources management, however, the resource-strategy file seems a little too complex.

Work to do:

• Remove huli keys
• Provided CRUD methods for storage management
• Mockup options data on serverless strategy

When requesting the same data for two components I want to ask for the data to the server only once so I can reduce unnecessary load.

Requests such as
"context": { "historic_pathologies": { "36b21ccb-567f-4740-a498-b8b8b174c6ab": { "id_user": 17 }, "66ee6d17-1343-4ae3-b7c3-66fe4475d41e": { "id_user": 17 } } }

Can be further optimized by grouping the ids with the same payload.

Create a reusable and extendable way to store common definitions like blocks (ie. ComponentDef)

Several main components are "hacking" the way of loading resources via children definition, but not including initially in view or as dettached elements (ie. list, timeline, multi-view). We should work a way of separating flows like having an option or flag to define if a child should be inserted automatically to the view or just load its resources on load.

When an error occurs during a save flow, we may want to either handle it in a custom way, using meaningful UI feedback, or let if fall back to a default handler, producing an unpredictable result.

However, even when the UI properly handled the save error, there wasn't a way to tell the save flow to stop there and don't call the default handler.

A way to handle this situation better is provided in PR #39

Sometimes, you only need to use a standard setData version with the event trigger side effect, without binding the whole fetch behavior, so providing a separate utility method for doing so might be useful.

We currently support only data preparation through a callback function pass by parameters to the save data binder.

this.saveDataBehavior = new SaveDataBinder({
component : this,
saveProxyCallback : $.proxy(proxy.save, proxy),
prepareDataToSave : this._prepareDataForRequest,
onComponentSaveSuccess : $.proxy(this._onSaveSuccess, this),
onComponentSaveError : $.noop
});

Certain scenarios may require a data preparation with promises like: third party services requesting a token/approval...