Class: StandardViewManager

StandardViewManager(dataManager, options)

new StandardViewManager(dataManager, options)

Parameters:
Name Type Description
dataManager DataManagerInstance.<M>
options
Source:

Members

acceptedChildViewManagerScopes :ExclusiveStack.<string>

Type:
Source:

attachedModels

Source:

childOptions

Source:

childViewManagers

Source:

componentViewDataHooks

Source:

externalWatchChildViewManagers

Source:

externalWatchDataHooks

Source:

id

Source:

isChildInfo

Source:

isWatcher

Source:

isWatcherChild :boolean

Type:
  • boolean
Source:

rootViewDataHooks

Source:

rootViewOptions

Source:

scope :G_S

Type:
  • G_S
Source:

soleModelId :string

Type:
  • string
Source:

Methods

addChildViewManagerToList(childViewManagerBuildOptions)

Parameters:
Name Type Description
childViewManagerBuildOptions
Source:

autoPopulateViewsFromExistingOrServerSide()

Called to prepopulate the internal models list from existing models, including ones read from server side HOW IT WORKS When viewReady is called, and the view manager is NOT a child (that will be auto triggered by parent) autoPopulate... checks if we have an existing model for the scope, and saves it in existing models list. If we have a server-side flag, it assumes the existing data was hydrated from the server side script. Therefore, when it calls onCommit with mutation create (cause its a directly created model), the flag isServerSideCreate is set to true. With this flag, the manager runs hookServerSideViews in onCommit, which calls the root component hook onViewAttach after spawning a new model for the view (s) - in the case of list view manager. The hookServerSideViews method will return the new view info (s) that will be used to complete the rest of the onCommit logic If the existing model was not server side, normal onCommit logic will run, i.e a new view with its associated attached model will be spawned, allowing view manager to autopopulate immediately they're added to scope by the data manager and init //Only thing is, because new children will not have been automatically triggered, have a method to reflag it to do so if late addition, during init (based on whether we go an existing models list or not)
Source:

buildChildViewManager(childViewManager, childInitArgs, preInitChildrenCbopt)

Parameters:
Name Type Attributes Description
childViewManager ListViewManagerInstance.<M, ChildScope>
childInitArgs ChildViewManagerBuildOptions.<M, ChildScope>
preInitChildrenCb genericParamFunction.<genericFunction> <optional>
Source:

canRunHooks(APIScope, forDirectMatchAndChildrenOnlyopt)

Parameters:
Name Type Attributes Description
APIScope NestedKeyOf.<M> | ArrayOnlyNestedKeys.<M> The original APIScope
forDirectMatchAndChildrenOnly boolean <optional>
Source:

dataComparator()

Source:

detachViewNodeFromRootParent()

The implementation below is for standard only
Source:

getLifeCycleInstance()

Source:

getMappedDataIdThatMatchesProperties()

Return a mappedDataId that matches the given properties Note: Was to do for global too, and have common comparator Could have been useful if say, a global id in higher scope (parent) to this But no. Redundant since in a nested scenario, it is same for all, since they have SAME parent
Source:

getModelIdForMappedDataId()

Source:

getOrderedArrayIndices()

So, have two versions. CORRECT WAY AS PER ALGO (just return empty queue. Join will handle the rest - check usage in data manager) Doing so because, this is NOT managing a list. So no particular index. Even if child Scope used to determine if ordered array indices valid (only if scope not model root)
Source:

getParentRootViewNode()

Gets the parentViewNode
Source:

getViewNodeForMappedDataId()

Source:

getWatcherChildViewManagers(childOptions)

Parameters:
Name Type Description
childOptions
Source:
Returns:

hasMappedDataId()

Source:

hookServerSideViews() → {ServerSideAttachedViewInfo}

Called AUTOMATICALLY when view is ready either for self or parent when init
Source:
Returns:
Type
ServerSideAttachedViewInfo

inflateOrderedChildViewManagers(childOptions)

Parameters:
Name Type Description
childOptions
Source:
Returns:

initViewManager()

HANDLE LIFE CYCLE Build the existing models list, cue to commit, which will create relevant attached models list as per Remove all attached views to model on destroy
Source:

invokeChildViewManagers(mappedDataId, invocation, completeCb)

Parameters:
Name Type Description
mappedDataId string
invocation
completeCb genericFunction
Source:

invokeRootComponentHooks(mutation, newData, oldData, mappedDataId, modelId, APIScope, invocation, completeCb)

Parameters:
Name Type Description
mutation DataManagerMutations
newData Partial.<ValueTypeOfNested.<M, APIReqScope>>
oldData Partial.<ValueTypeOfNested.<M, APIReqScope>>
mappedDataId string
modelId string
APIScope APIReqScope MUST be the SAME as the request scope. Otherwise, hooks won't fire {rootComponentHooksInvocation['masterWorkingModel']['scopedOptions']['views']>} invocation
invocation
completeCb genericFunction
Source:

onCancel()

Source:

onCommit()

Source:

onError()

Source:

onMutate(modelID, newModel, oldModel, APIScope)

The APIscope is the scope of the mutation request A view manager can take a scope larger or smaller than it, as long as it's related, meaning its a parent or child to it Therefore, only valid operation, where data is not null, is reducing API scope data to view manager's scope. This is for LARGER scopes where it is a child. For where the scope is a child, only fire where child matches or is parent. How do we pick that up then? - Infer a parent from a child: child will start with parent scope
Parameters:
Name Type Description
modelID string
newModel Partial.<ValueTypeOfNested.<M, ReqScope>>
oldModel Partial.<ValueTypeOfNested.<M, ReqScope>>
APIScope ReqScope
Source:
To Do:
  • ensure data can pass as an array, for a simple, single render list view

reduceHookDataToScope(apiModel, currentDataScope, hookScope, mappedDataId)

Working like the data comparator now
Parameters:
Name Type Description
apiModel
currentDataScope ReqScope
hookScope HookScope
mappedDataId string
Source:
Returns:

registerViewDataHooks()

Source:

removeAttachedModel(targetMappedDataId)

Parameters:
Name Type Description
targetMappedDataId string
Source:

runRootAndViewNodeBuild()

The implementation below is for standard only
Source:

setChildViewManager()

Source:

setExternalWatchChildViewManager()

Note. This one doesn't call init for current view manager, since no need to set scope
Source:
To Do:
  • To be implemented

setExternalWatchDataHooks()

Source:

setWatcherChildViewManagerOptions(options)

Parameters:
Name Type Description
options
Source:

spawnAttachedModels(modelId, attachedViewNode) → {string}

If ordered array index issues, root cause here (or starts here - getOrderedArrayIndices)
Parameters:
Name Type Description
modelId string
attachedViewNode Element
Source:
Returns:
mappedId
Type
string

updateAttachedModel(targetMappedDataId, viewNode)

Parameters:
Name Type Description
targetMappedDataId string
viewNode Element
Source:
Returns:

validateSelfAsChild()

Allows self to be child. Else, throws error
Source: