Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs)

Good call about the simulation running more often than necessary with this scheme, I didn't notice that.

I originally looked into an approach similar to what you are suggesting, the thing I didn't find a good solution for is step 3:

selectDataSourcesUIAttributesMap = 
export const selectDataSourcesUIAttributesMap = createSelector(
  [(context: StreamEnrichmentContextType) => context.dataSourcesRefs],
  (dataSourcesRefs) => {
    return dataSourcesRefs.reduce(
      (uiAttributesMap, dataSourceRef) =>
        Object.assign(uiAttributesMap, {
          [dataSourceRef.id]: dataSourceRef.getSnapshot().context.uiAttributes,
        }),
      {}
    );
  }
);

// and use it when rendering the table docs
const dataSourcesUIAttributesMap = useStreamEnrichmentSelector((snapshot) =>
  selectDataSourcesUIAttributesMap(snapshot.context)
);

Since the dataSourcesRefs don't change, this won't trigger an update so it will be stuck on the memoized value if e.g. the name of a datasource changes.

I can see two ways of handling it:

• We could always calculate the uiAttributesMap on any change and then do a deep equality check - this feels pretty dirty and still recalculates the uiAttributesMap over and over
• We could have the datasource state machine pass the ui attributes up to the enrichment state machine and keep it in the context there as well - this could be memoized in a clean way. However, I really dislike that it will keep the same information in two places (the data source machine context and the enrichment context)

If thought the trick of passing down the data again after the data source changed circumvented this problem, but of course it's even worse if it simulates more often than necessary.

Do you have another idea? I guess the option about passing updated ui attributes to the enrichment machine and managing the uiAttributesMap there is the cleanest approach.

I should have probably highlight that more, but in the uiAttributes I'm not considering anymore the name of a data source (which btw can be undefined), but the always present dataSource.type

Since the dataSourcesRefs don't change, this won't trigger an update so it will be stuck on the memoized value if e.g. the name of a datasource changes.

With that value combined with the data source id and the colors computed only once, the uiAttributes would never change and there is no need for a rerender based on the data source change, which also reduces the recomputations :)

Basically, instead of enforcing a change of colors and initials on the avatar (which IMO, would also feel inconsistent and make the user feel lost if slightly changes the name and the color is recomputed with a different one), what I suggest is to guarantee a consisten ui definition associated with a data source based on the color and the initials of random-samples | kql-samples | custom-samples, which would also let the user know about the type.

OTOH, if you'd still like to keep the name around for the tooltip for example, it's just about removing the memoization with the selector and compute list with the display name attached:

export const selectDataSourcesUIAttributesMap = (context: StreamEnrichmentContextType) => {
  return context.dataSourcesRefs.reduce((uiAttributesMap, dataSourceRef) => {
    const dataSourceContext = dataSourceRef.getSnapshot().context;
    return Object.assign(uiAttributesMap, {
      [dataSourceRef.id]: {
        ...dataSourceContext.uiAttributes,
        displayName: dataSourceContext.dataSource.name,
      },
    });
  }, {});
};

Doing so, it will surely go through more updates, but that's probably a trade-off we could live with. As far as this doesn't affect the simulation lifecycle looks good to me.

Thanks @tonyghiani As discussed offline, I made the following changes:

• Move the leading control column to a wrapper component so PreviewTable doesn't get too big. Theoretically we could also move the whole table control stuff (ordering and so on) there, but that seems general enough so we would want it in other places too so I left it in for the moment.
• Change the way the data source information is passed to the avatar - it's just subscribing to the respective data source machine in the control column component directly. This means that only the data source index needs to be passed down along with the documents themselves.
• Make the color a function of the index, so duplicate colors are unlikely
• Fall back to the data source type instead of the index for naming if there is no name provided
• Same minor renames

Should be ready for another look

I agree that keeping the color assignment stable even if data sources are deleted is helpful - I changed the code to do that.

Based on that I also noticed an issue - when deleting a data source the table is rerendering immediately with samples still part of that now-deleted data source. I made the code robust to this situation - we can probably avoid it by making sure data is recalculated immediately, but it's probably good to not break the whole UI on this situation anyway.

Ready for another look.

💚 Build Succeeded

• Buildkite Build
• Commit: a9d9177

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

History

• 💚 Build #318354 succeeded 9102798
• 💛 Build #317933 was flaky d754ccf