[Lens] Typing into the dimension label input is not stable

[wylieconlon]

Steps to reproduce:

1. Go to the Metric visualization type
2. Create any metric
3. Attempt to insert a totally new title into the text box, and then try to modify the middle of your existing title

Previously, we were able to determine which text changes were coming from local vs external sources, but something has caused a regression in this behavior. My theory here is that it's been caused by the use of activeData in the dimension editor, which was only added recently and hasn't shipped to users yet.

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[flash1293]

This is happening because of the async state setting for datasources. After onChange is called, the debounce logic assumes there are no unflushed changes anymore:

kibana/x-pack/plugins/lens/public/shared_components/debounced_value.ts

Line 36 in e3c3b6f

unflushedChanges.current = false;

However, as the state change is only submitted in the next tick, this isn't true anymore.

The most stable fix is to not do async state updates for the datasource. @wylieconlon can you gauge how bad this would be in terms of performance?

I also played around with another approach - waiting for a bit after onChange got called, assuming unflushed changes for this time:

  const flushHandle = useRef<NodeJS.Timeout | undefined>();

  const onChangeDebounced = useMemo(() => {
    const callback = debounce((val: T) => {
      onChange(val);
     // do not reset unflushed flag right away, wait a bit for upstream to pick it up
      flushHandle.current = setTimeout(() => {
        unflushedChanges.current = false;
      }, 256);
    }, 256);
    return (val: T) => {
      if (flushHandle.current) {
        clearTimeout(flushHandle.current);
      }
      unflushedChanges.current = true;
      callback(val);
    };
  }, [onChange]);

I couldn't break it even with 6x CPU slowdown.

[wylieconlon]

@flash1293 the async update isn't currently for performance reasons, it's for integration with Monaco. What if the updateDatasource returned a promise that resolves when the update is submitted to React, could that be used to indicate that the debouncing is dirty until the result is fully submitted? Alternatively, this all might go away once we use Redux for the datasource state.