Set uiState to Vis from visualization - #15549

looks good, i will wait for the tests to pass and also give it some more testing before approving :)

@thomasneirynck What would you like to fix there? That an editor might want to pass through the uiState to the $scope it generates? Since this documentation doesn't talk at all about how to actually render anything in this render method, and also doesn't tell anything about what to do with visData, searchSource, etc. or any other parameter that would be expected on the scope, I don't see the benefit of talking about uiState in that place.

If the custom editor doesn't by chance render the <visualization> element within its template it would anyway not be needed. And if it renders it, all the other things would also be needed, that we don't talk about there.

@timroes fair enough, we skipped over these properties for convenience as not to clutter the doc. So this is only tangentially related to this PR. The mismatching doc doesn't seem to right approach in hindsight. If we continue not to document them, this is a sign the Editor-API needs work. After all, when people write custom editors, they will see 3 (formerly 2) extra parameters passed in, that are very mysterious. And there is a possibly meaningful parameter in there (updateStatus), that goes unused in our internal code. Overloading signatures isn't a native feature of JS and imho there's no compelling reason to insist on having it here.

So if we're going to expand on the API-method, I'd use the opportunity to improve on getting the doc synced with the actual implementations. Couple of approaches to consider:

• we document all arguments and briefly explain what they are, adding a DEPRECATED note on all but the visData. That we use them in the default-editor we can then chalk up to being legacy code. Other people should not.
• the default editor gets a one-off .renderWithState(data, searchSource, uiState) method, and we check on its presence in the visualize_editor on which one to call. That gives us an internal special code-path, invisible and undocumented to other users.

The updateStatus flag actually I do think is meaningful, so we can consider keeping it (and documenting it). If so, I'd reorder updateStatus to be 2nd parameter for symmetry.