Tabbed company lifecycle

[rivernews]

Problems

• [ ] When updating (changing) company label, how to reflect in local redux -- how to change to corresponding bucket? (e.g. target/applied/interviewing/archived company)
  • Let current redux factory allow custom reducer.
  • Apply custom reducer for company
  • After looking at our redux: the saga controls the entire thing, including when to dispatch actions for each request status (requesting, success, failure), api calls, and when to write to store (reducer). Particularly, the success action will fire the reducer; other action will not store object (will change meta like requesting status though).
  • Having the insight above, we can modify the saga behavior, particularly what to do when dispatching success action. At this point, the PATCH api call is done, and we have the jsonResponse representing the changed data. Also, we have formData, which represents the original data.
  • Now, if we see a label change, we 1) add to new label group store, 2) remove original label group store. That is, 1) dispatch a success/CREATE action of the new label redux (company). 2) dispatch a success/REMOVE action of the original (current) label redux. This means we will have to reference other actions into current saga/redux, which sounds a but hacky, but hey, dispatching action does not carry out any api calls, so it's pretty safe to do -- it just modifies local redux store, which is exactly what we want.
  • This also clarifies the role of saga and actions.
• [ ] When company created...which "bucket" should it be placed.
• [ ] Avoid duplicated fetching -- remove the "all" tab.
• [ ] Side issue - interrupt uneeded request using Axio and abort controller.

[rivernews]

After considering UPDATE company label, we found a major issue when visiting company detail page: we cannot locate the right bucket given only the uuid. This has to be solved by some other approaches. Due to the fact that too many troubles are found, we need to review the entire lifecycle of company, in order to figure out all changes required:

1. [ ] Fetch company: login finished, then fetch in saga. After got jsonResponse, reflect in local redux by dispatching actions. If different company group has their own redux resource set, then dispatch all their actions.
2. [ ] Create company: Button "Create Organization" --> Create company form --> submit form --> place the company in the right redux store bucket (company group, one of target, applied, interviewing and archived). Default label group to "Target".
3. [ ] Update company: Edit company --> company update form --> make changes --> submit form --> remove company in current bucket, place in destination bucket.
4. [ ] Visit company detail: in home page, click on a company. In the company detail page, pull out the company from redux by uuid. Currently does not support grouped company.

Review and audit

Current approach: standalone "buckets"

✅ 1. Fetch Each company group has its own saga, reducer and actions. Have to fire their action one by one in saga to fetch all of them. Lifecycle 1 will suffice automatically -- we just fire trigger action in auth saga, and the rest will be handled.

🕑 2. Create We will have to place new company in the right bucket. Default to Target. In company form, probably need a custom submit callback to dispatch the right action of right bucket. If not handled, will place all company in "All" bucket.

🕑 3. Update Handled: create in destination group bucket, and remove from current group bucket. However, if we want to change the structure of bucket store, this needs to be rewrite.

🕑 4. Visit Not handled currently. The company detail page is another route. We rely on only uuid to pass information between routes, and uses uuid to retrieve the company. Under the current company bucket store structure, we have no idea which bucket contains this uuid company. At worst have to traverse alll bucket, which is a no no.

✅ 5. Pagination Handled, since filter will work in their own url namespace.

If we go for this approach, we definitely need to remove the "All Company" tab and all its store, as it interferes with the mechanism, and can mislead that things work while in fact it's broken.

Proposed approach: single pool + indices group

This is to solve the Lifecycle 4 trouble, so we avoid having to find which bucket to look into. If we have a single pool -- single source of truth, we simply pull from this pool. No bucket even needed. What about update? Only matters in the home page, i.e. master page, level, where groups have to be in the right tab.

However we need to mind how pagination work in this approach. When each tab / each company group is fetching their company page(s), they all contribute to a single company pool. Use infinite scroll as an example, new pages will be reduced and merged into single pool. --> Looks like not much concern about this.

Let's review how this approach solves the CRUD operations.

• [x] Fetch: the fetch needs to happen in grouped company redux, not the company "pool" redux -- so that pagination in each tab group can be done easily. However, the behavior of changing local store needs to be altered -- we can override success saga to do this:
  • Where to dispatch the fetch action? Right after login. Dispatch group company action; for company pool redux, we'll dispatch them manually later.
  • For each company group redux, override their success saga
  • In success saga handler, context is - crudType is LIST, so jsonResponse is a list, not single. Instead of dispatching group company's action, dispatch "pool" redux LIST action -- success action, to write into local store of pool redux.
  • We want group company redux store to serve as "pointers" (reference) to companies in pool. So, we dispatch group redux action to store the list of uuid in jsonResponse. To reuse existing redux toolset, we may define a data model Reference, which is just a uuid, or string in Javascript. Since this type is so simple, we may not need the data model, actually. Can we just use ad-hoc value?
  • Now, we have a list of uuids in group company store, and a list of company objects in pool redux. We can now render companies in each tab -- access company by companyPool[uuid].
• [x] Create:
  • Where to start (dispatch Create action)? In the company form, onSubmit. We need to dispatch action in normal function, no saga here. But, dispatching TRIGGER action will lead to running saga, so it's the same as in fetch, eventually.
  • Several ways -- one way is to emphasize reuse. So we: 1) dispatch company pool redux action using formData; 2) use previous action's callback func arg to ensure the following is run after company data stored in pool: dispatch group company redux action, pass over list of uuid from jsonResponse -- we may need to refactor to have access to jsonResponse in callback func. If we don't define a data model for Reference, we can directly pass over uuids to group company TRIGGER action.
  • Another way, is to completely override CREATE success saga. So far we only wrote the UPDATE success saga, where we limit crudType to UPDATE. Now we write a new saga handler for create, it will do: 1) dispatch company pool redux CREATE/SUCCESS action. 2) dispatch group redux CREATE/SUCCESS action with uuid from jsonResponse. Pass over this CREATE saga handler to group company redux factory func.
• [x] Update:
  • We already setup the saga handler part. We just need to alter the saga handler behavior. 1) First we need to dispatch company pool UPDATE action, which is the same as original company pool redux. 2) Next, likewise, only do remove/create across group company redux when label is changed.
• [x] Visit (detail page)
  • This should remain the same, no additional change needed, because it will just use company pool redux, which is the original company redux.
• [x] Pagination
• [x] But, challenges: Need a separate redux toolset. Can we reuse existing redux factory? If we reuse existing, we may not need. Of course, there is some overhead, like for Reference data model, we do not need API call for it -- only the actual Company data model needs to. So we may not need its saga. So when creating group company redux, we can refactor code to exclude create saga resources. But this can be done later; implement the main functional part first.

[rivernews]

Remaining Issue: relational data lifecycle

When an application is updated, its redux update to application store. But not the "embed" application in company object. Same for all CRUD operations, and for applications & application status links.

• Application
  • [x] READ / LIST
  • [ ] CREATE
  • [ ] UPDATE
    • Current form will submit to API using its own redux toolset, and database will be updated.
    • Problem is local redux not reflected. Current redux will only update application redux store, not the embedded application in company. We want to update the embedded application.
    • The redux official doc suggests a relational shape store - which is what we've done before. We can review this paradigm and see if that is better, but has to solve our requirements:
      • Grouped store w/ quick access
      • Pagination based on grouped company
      • Let's imagine: we save data into redux store in a relational, normalized way. But, our API (can, but can opt-out) serves embedded, de-normalized data. The API's embedding solves the pagination issue -- we will only receive data strictly related to companies of page #1, etc. How about group store? How about our current "ref" approach? Seems to already solve this. Then, what else kind of change should we make?
      • We need actual application/application status data stored in their own redux store.
  • [ ] DELETE
• Application status
  • [x] READ / LIST
  • [ ] CREATE
  • [ ] UPDATE
  • [ ] DELETE

[rivernews]

Proposed Solution to Relational Data Lifecycle

• Remain separated object store / redux
• Remain company pool + grouped ref redux
• Remain dispatching grouped company action after login
• [ ] Add logic: after receive jsonResponse, store relational data in their redux store by their SUCCESS action.
  • When to do this processing relational data?
  • [x] CRUD: 1) Read/List/Fetch -- of course, will store into each relational data's redux. This is in Company's redux.
  • [x] 2) Create -- likewise, will need to store into each redux. This is in application/status redux.
    • Application's existing redux saga -- ok we want that, we want data stored in application store. But, we want to add to company.applications[], add the new app uuid.
  • [x] 3) Update -- not company, update company can just use existing logic; we mean update application/status. Well, can just post update to application's store. Because company references to application store, so no need to modify company.
  • [ ] 4) Delete -- we need to update both company & application. In application DELETE action's saga handler, DELETE application, then UPDATE company.
• [ ] Add logic: when render application and application status, use their own redux store + their uuid in company.

[rivernews]

Dealing with Normalization

Since we are doing normalization, we need to cover a wide range of saga handler, actually even all of them. The main challenge is having to accessing redux resource of other objects when in an object redux saga handler. Because in the entities, you might have multiple types of objects normalized and surfaced up.

Ideally, we want the factory to handle this rather than having multiple saga override/done handler. There are several ways to do this and we'll explore them here.

Manifest of normalization info in factory func arg

const reduxFactory = (..., normalizeManifest) => {
    reduxResources.saga = function*() => {
        const jsonResponse = await fetch(...);

        // TODO 1: check normalizeManifest arg availability

        const normalizedData = normalize(jsonResponse, normalizeManifest.schema);
        const objectNormalizeData = normalizedData.entity[normalizeManifest.objectEntityKey];
        const relationalNormalizeData = normalizeManifest.relationalEntityKeys.map(key => normalizedData.entity[key]);

        // deal with primary object actions
        if (crudKeyword == DELETE) {
            .... // same as existing
        }
        else {
            .... // same as existing
        }

        // deal with relational entities actions - for LIST/CREATE/UPDATE/DELETE - 
        // TODO 2: check  normalizeManifest availability
        for (let entityName of normalizeManifest.relationalEntityKeys) {
            // TODO 3: what kind of CRUD needs to be applied? May not be the same as the primary object
            const entitySuccessAction = normalizeManifest.actions[entityName][?crudKeyword?][RequestStatus.SUCCESS].action;
            const entityData = normalizedData.entities[entityName];
            // TODO 4: how to deal with single/list response?
            yield put entitySuccessAction(entityData / { results: entityData });
        }
    }
}

Discussion

Case study: company redux operations. Let's see its LIST/CREATE/UPDATE/DELETE scenarios.

Company LIST: ✅ Application | | | ✅Status For company, we should apply LIST/SUCCESS action(listResponse). For application, we should apply LIST/SUCCESS. For status (application status), we should also apply LIST/SUCCESS.

Company CREATE: ✅ Application | | | ✅Status For company, we should apply CREATE action(singleResponse). For application, we should apply CREATE action. For application status, we should apply CREATE action.

Company UPDATE: ✅ Application | | | ✅Status For company, we should apply UPDATE action(singleResponse). For application, we should apply nothing. -- The update is totally company's own business. For application status, we should apply nothing.

Company DELETE: ✅ Application | | | ✅Status | | | ✅ Cascade DELETE del application ⏸ Cascade DELETE del company For company, we should apply DELETE action(singleResponse, formData). For application, we should apply DELETE action(undefined, listResponse) < we may need to change DELETE action to support list (multiple) delete. For application status, we should apply DELETE action(undefined, listResponse)

Generalization for Application / Status? Yes, as long as the relationship is like Company (primary) <------ Application (relational), or primary <----- multiple relational, then this paradigm will suffice.

Challenge of Cascade Delete

We now choose to handle nested field in done saga, and have factory saga handle 1st level rellational data deletion.

The problem is, at the time of done saga, we lose company and application in store. While we have formData to deliver company data, we lose application in store. If we don't have application, we can not de-normalize statuses. Otherwise you'll have to do a O(n) filtering on status store.

[rivernews]

Dealing with Circular Dependency

While implementing Cascade DELETE, we found a circular dependency:

application-redux: ApplicationRestApiRedux --needs--> appliation-redux: ApplicationNormalizeManifest

application-redux: ApplicationRestApiRedux --gives--> application-redux: ApplicationActions (gives action, reducer, saga)

appliation-redux: ApplicationNormalizeManifest --needs--> application-normalize: ApplicationStatusActions --needs--> statuses-custom-saga: applicationStatusDoneCreateSuccessSagaHandler --needs--> application-redux: ApplicationActions

---

To summarize:

• Creating "application-redux", pre-needs "application-normalize" needs "status action" created from "status-redux"
• Creating "status-redux", pre-needs status custom saga needs "application actions", needs to be created from "application redux". Circular dependency formed.

[rivernews]

68 et al., had completed this feature.