expand orgId enrichement to other content types, and/or replace with enrichment w/ ownerUser?

[tomwayson]

Hub.js currently only fetches the orgId for a content for Hub-created web maps (we were being conservative in order to avoid making this xhr when we didn't need it).

However, now I've learned that the Hub app's content views send contentOrgId w/ telemetry. The app fetches the ownerUser for all content types and we get the id from content.ownerUser.org.id.

See: https://github.com/ArcGIS/opendata-ui/pull/9667#issuecomment-858841298 for more info.

Determine if hub app needs the whole ownerUser, or just the orgId and move that logic into fetchEnrichments.

cc @rweber-esri @juliannemarik

[tomwayson]

I forgot about #414, so looks like we need at least the user's name in addition to the org id, so sounds like we should update the enrichment to set ownerUser and not just orgId. We can then also set orgId (and perhaps other org properties)? later in enrichProperties.

It appears that we are fetching this for all content. I guess it should be included by default in fetchEnrichments().

[tomwayson]

Plan:

• replace orgId enrichment w/ a new ownerUser enrichement
• after enrichments are fetched, call a new _processFetchedEnrichments fn instead of just _enrichDates
• _processFetchedEnrichments will now call _enrichDates and then also have new logic for updating the content's orgId and org properties based on ownerUser

NOTE: that the current app code for fetching the owner user is here:

https://github.com/ArcGIS/opendata-ui/blob/master/packages/opendata-ui/app/services/content.js#L307-L332

That code not only fetches the user, but enriches the user object and makes a few additional requests for org info, etc. TBD how much of that needs to be done w/in enrichContent().

[dbouwman]

Enrichment Streamlining

Single entry fn

enrichContent(
  type:string,
  content:Partial<IHubContent>,
  requestOptions: IHubRequestOptions
  ):Promise<IHubContent> {...}

For composition, we should have a single input and return type for all the enrichment functions

export interface IEnrichmentOpts {
  content: Partial<IHubContent>,
  requestOptions?: IHubRequestOptions
}

Each enrichment should handle merging in any errors so we have no processing "at the end"

If there is more complex logic re: when an enrichment should be run, do that inside the enrichment vs outside... then all the logic is in one place

Each enrichment fn has this signature:

// All enrichments use promises, so we can treat them the same for composition
const enrichDates(enrichmentOpts: IEnrichmentArgs):Promise<IEnrichmentOpts> {..}

Declarative Composition:

Things to capture:

• what should always be done
• what should be done for specific types
• what should be done for "summary" vs "complete"
  • basically don't super-enrich things we'll show in a list

const enrichmentMap = {
  common: {
    simple: [
      // if these are strings, we have to map into a set of functions
      // but we could also import all the fns and just list them, so
      enrichDates,
    ],
    complete: [
      enrichDates,
      ownerUser
    ]
  }
  types: {
    hubSiteApplication: {
      simple: [...],
      complete: [ domainEntries ]
    },
  }
}

Then we look up based on the type, merge common w/ any type specific stuff, and return a composition

// async pipe fn
const pipe = (...functions) => input => functions.reduce((chain, func) => chain.then(func), Promise.resolve(input));

getEnrichments(type, content) {
  const base = getWithDefault(enrichmentMap, `common.${type}`, []);
  const typeName = camelize(content.type);
  const extentions = getWithDefault(enrichmentMap, `types.${typeName}.${type}`, []);
  return [...base, ...extensions];
}

enrichContent(type: string, content:Partial<IHubContent>, ro):Promise<IHubContent> {
  const enrichments = getEnrichments(type, content);
  const opts = {content, requestOptions} as IEnrichmentOptions;
  return pipe(enrichments)(opts).then((result) => {
    return result.content;
  });

}

[dbouwman]

Discussion thoughts...

const typeName = camelize(content.type);

const typeName = getTypeName(content);

getTypeName(content: IContent): Promise<string> {
   let typeName = camelize(content.type);
   if (typeName === 'table') {
     // if url.indexOf('mapservice') {

 
     }
   }


}

const enrichmentMap = {
  common: {
    simple: [
      // if these are strings, we have to map into a set of functions
      // but we could also import all the fns and just list them, so
      enrichDates,
    ],
    complete: [
      enrichDates,
      ownerUser
    ]
  }
  types: {
    hubSiteApplication: {
      simple: [...],
      complete: [ domainEntries ]
    },
   mapServiceLayer: {
     complete: [iterateLayer]
   }
  }
}

ugly jsbin w/ rough prototype of things -> https://jsbin.com/kipafum/1/edit?html,js,console,output

[tomwayson]

The current system allows users to pass in an arbitrary set of enrichments to (or [] to not fetch any and only do the sync enrichments of urls and dates). Basing this on enrichmentMap would require users to use predefined (named) sets of enrichments.