🌊 Streams: Use better default field

[flash1293]

This PR passes the current sample documents to the default form state generation for new processors to pick a good default field.

The logic that's actually employed for dissect and grok is the following:

• Go through all docs and order string fields occurring by how many values they have
• Pick the top one from a list of "well known" fields that probably make sense (in case of a tie, go by a the ordering of the well known fields)
• If no field is found this way, just leave it empty - this still shows the full table and the user can pick the field they care about

Especially for otel this should be helpful.

[flash1293]

/ci

[flash1293]

/ci

[elasticmachine]

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

[thomheymann]

Looks good but would add a few tests for the detection logic (see below)

[tonyghiani]

@flash1293 a couple of things:

• WRT computing the default field for each processor, why not keep the static definition of the default forms (switching the default to an empty string) and merge the definition where required on the processor forms? This would keep every piece well decoupled and we would just need to get the default field with a selector, removing any other change done to the existing interface and making the default form static again. In pseudo-code:

// selectors.tsx
export const selectDefaultField = createSelector(
  [(context: SimulationContext) => context.samples],
  (samples) => getDefaultTextField(samples)
);

// then in the components
const defaultFied = useSimulatorSelector((snapshot) => selectDefaultField(snapshot.context));

const formState = { ...getDefaultFormStateByType(type), field: defaultFied };

The changes would be minimal, and we don't need to change anything on the existing previewDocuments selector.

• Do we need to use the previewDocuments? Why not just the base samples?

[flash1293]

@tonyghiani I thought about this, but a good suggestion depends on the processor (e.g. for the date processor we wouldn't suggest the same fields). It's not even a given that all processors have a field to operate on.

It could still be kept in the component, but it seems like it doesn't belong there.

Do we need to use the previewDocuments? Why not just the base samples?

Not sure, that would work too. I thought it's always nice to stay consistent and base all decisions on what the user currently sees so they can understand where things are coming from.

[tonyghiani]

I thought about this, but a good suggestion depends on the processor (e.g. for the date processor we wouldn't suggest the same fields). It's not even a given that all processors have a field to operate on.

Agree, the approach I was proposing would still work well since we have the processor type in scope

// selectors.tsx
export const selectDefaultField = createSelector(
  [
    (context: SimulationContext) => context.samples,
    (type: ProcessorType) => type
  ],
  (samples, type) => getDefaultTextField(samples, type)
);

// then in the components
const defaultFied = useSimulatorSelector((snapshot) => selectDefaultField(snapshot.context, type));

const formState = { ...getDefaultFormStateByType(type), field: defaultFied };

[flash1293]

Right, I see - no strong opinion, I can change it like that

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 30db3da

Metrics [docs]

Async chunks

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

id	before	after	diff
streamsApp	405.7KB	406.6KB	+979.0B

History

• 💚 Build #292773 succeeded 50a8606
• 💚 Build #291143 succeeded b78ea82

[kibanamachine]

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/14469423743

[kibanamachine]

💔 All backports failed

Status	Branch	Result
❌	8.x	Could not create pull request: Unexpected end of JSON input

Manual backport

To create the backport manually run:

node scripts/backport --pr 217478

Questions ?

Please refer to the Backport tool documentation

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 217478 locally

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 217478 locally

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 217478 locally

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 217478 locally

[flash1293]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation