Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dev tools application #7334

Closed
epixa opened this issue May 31, 2016 · 9 comments
Closed

Dev tools application #7334

epixa opened this issue May 31, 2016 · 9 comments

Comments

@epixa
Copy link
Contributor

epixa commented May 31, 2016

We should create a "dev tools" application in Kibana core that allows plugins to register tools that are really only appropriate for advanced and debugging functionality such as profiling. The individual plugins would still control all of the functionality of the tools, but they'd register themselves with the dev tools app and be listed under it rather than each of them having their own sidebar link.

Console should be moved under this dev tools app instead of having a top level link.

The whole "plugins register with the dev tools app" functionality should be similar to the way plugins can register with the upcoming management app that's being created in #7135.

The exactly experience of the dev tools app should differ slightly from management in that there will not be an overview page. Instead, clicking on dev tools will bring you to console by default, and then all other dev tools will show up as siblings in the nav. This would be similar to how your browser dev tools work, for example.

@epixa
Copy link
Contributor Author

epixa commented May 31, 2016

/cc @polyfractal

@epixa
Copy link
Contributor Author

epixa commented May 31, 2016

@uboness Do you think we should break the dev tools app by product like we're doing with management or just leave it as a clean slate? I prefer the latter at the moment since I don't envision the dev tools exploding in number (e.g. > 10) in the short term.

@uboness
Copy link

uboness commented May 31, 2016

I prefer the latter at the moment since I don't envision the dev tools exploding in number (e.g. > 10) in the short term.

++ on keeping clean slate for now. It'd be strange to have only ES category there at the moment. I think calling the profiler "Search Profiler" pretty much says it's for ES. And console... well, for now it's just for ES but surely later on it'll be for Kibana & LS as well

@polyfractal
Copy link
Contributor

++ for clean slate as well. I think it'll be quite a while before we have enough tools to justify more internal classification.

@polyfractal
Copy link
Contributor

Friendly poke, any status update? :)

@lukasolson
Copy link
Member

image

I've created a dev-tools registry that allows you to register dev-tools with a similar API to the management interface:

// in your main app file
uiExports: {
  devTools: ['plugins/console/console']
}

// in plugins/console/console.js
import devTools from 'ui/registry/dev_tools';
devTools.register(() => ({
  order: 1,
  name: 'console',
  display: 'Console',
  url: '#/dev_tools/console'
}));

The problem is that now, the files for the app are included from a different scope... Before, they were being loaded completely separately to the Kibana app... and now, because they are a registry and treated the same as other registries (chromeNavControls, managementSections, etc.) the files of the app are included from the scope of the Kibana app itself. For example, when I require('ace'); I'm no longer getting the ace defined in console/public/webpackShims/ace, but rather the ace in /webpackShims/ace which is causing problems (and not just for this library).

I'm working through resolving these issues... @polyfractal If you want to take a look and see what you'd need to do, you can take a look at the feature/dev-tools branch in my fork.

@polyfractal
Copy link
Contributor

Awesome, thanks for the update! I'll take a look at your branch and see if I can start to make my code compatible.

@clintongormley
Copy link
Contributor

@lukasolson are we likely to see this for beta1? I'm just hoping we can get the profile UI in before feature freeze

@lukasolson lukasolson added the WIP Work in progress label Sep 2, 2016
@polyfractal
Copy link
Contributor

@lukasolson Did DevTools happen to make the cutoff before feature freeze?

@lukasolson lukasolson added PR sent v5.0.0-beta1 and removed WIP Work in progress labels Sep 7, 2016
jbudz pushed a commit that referenced this issue Dec 18, 2023
`v90.0.0`⏩`v91.0.0-backport.0`

⚠️ While this upgrade pings many teams and has a large code diff, **the
majority of the changes are snapshots or tests-related** and do not
touch source code, so should theoretically only need a code review and
not dedicated QA.

The changes in EUI that required a large swathe of these updates are:

- **EuiPopover** removed an extra unnecessary `<div>` wrapper on its
anchors, which affected many snapshots and a few CSS overrides, which
should have been updated
- **EuiButtonGroup** now renders `<button>` elements instead of `<input
type="radio">` elements for single selection, which affected both
snapshots and E2E tests
- **EuiSuperDatePicker**'s absolute date input now requires an `Enter`
keypress when parsing dates (affected E2E tests)
- **EuiComboBox**, when rendered with `singleSelection={{ plainText:
'true' }}`, no longer renders a pill (i.e. text). This combobox type now
behaves more like an `EuiFieldText`, where the selection is rendered via
input `value` instead. This affected a high amount of E2E tests (both
FTR and Cypress), both in terms of updating assertions and changing
selections, but should **not** significantly affect user experience -
see elastic/eui#7332 for more.

---

##
[`v91.0.0-backport.0`](https://github.com/elastic/eui/tree/v91.0.0-backport.0)

**This is a backport release only intended for use by Kibana.**

- Added `esqlVis`, `pipeBreaks`, and `pipeNoBreaks` icon glyphs.
- `EuiSelectable` now allows configurable text truncation via
`listProps.truncationProps`
([#7388](elastic/eui#7388))
- `EuiTextTruncate` now supports a new `calculationDelayMs` prop for
working around font loading or layout shifting scenarios
([#7388](elastic/eui#7388))

**Bug fixes**

- Fixed a bug with `EuiSelectable`s with custom `truncationProps`, where
scrollbar widths were not being accounted for
([#7392](elastic/eui#7392))

## [`91.0.0`](https://github.com/elastic/eui/tree/v91.0.0)

- Updated the background color of `EuiPopover`s in dark mode to increase
visibility & contrast against other page/panel backgrounds
([#7310](elastic/eui#7310))
- Memoized `EuiDataGrid` to prevent unneeded re-renders
([#7324](elastic/eui#7324))
- Added a configurable `role` prop to `EuiAccordion`
([#7326](elastic/eui#7326))
- Added a configurable `role` prop to `EuiGlobalToastList`
([#7328](elastic/eui#7328))
- For greater flexibility, `EuiSuperDatePicker` now allows users to
paste ISO 8601, RFC 2822, and Unix timestamps in the `Absolute` tab
input, in addition to timestamps in the `dateFormat` prop
([#7331](elastic/eui#7331))
- Plain text `EuiComboBox`es now behave more like a normal text
field/input. Backspacing will no longer delete the entire value, and
selected values can now be double clicked and copied.
([#7332](elastic/eui#7332))
- `EuiDataGrid`'s display settings popover now allows users to clear the
"Lines per row" input before typing in a new number
([#7338](elastic/eui#7338))
- Improved the UX of `EuiSuperDatePicker`'s Absolute tab for users
manually typing in timestamps
([#7341](elastic/eui#7341))
- Updated `EuiI18n`s with multiple `tokens` to accept dynamic `values`
([#7341](elastic/eui#7341))

**Bug fixes**

- Fixed `EuiComboBox`'s `onSearchChange` callback to pass the correct
`hasMatchingOptions` value
([#7334](elastic/eui#7334))
- Fixed an `EuiSelectableTemplateSitewide` bug where the `popoverButton`
behavior would break if passed a non-DOM React wrapper
([#7339](elastic/eui#7339))

**Deprecations**

- `EuiPopover`: deprecated `anchorClassName`. Use `className` instead
([#7311](elastic/eui#7311))
- `EuiPopover`: deprecated `buttonRef`. Use `popoverRef` instead
([#7311](elastic/eui#7311))
- `EuiPopover`: removed extra `.euiPopover__anchor` div wrapper. Target
`.euiPopover` instead if necessary
([#7311](elastic/eui#7311))
- Deprecated `EuiButtonGroup`'s `name` prop. This can safely be removed.
([#7325](elastic/eui#7325))

**Breaking changes**

- Removed deprecated `euiPaletteComplimentary` - use
`euiPaletteComplementary` Instead
([#7333](elastic/eui#7333))

**Accessibility**

- Updated `type="single"` `EuiButtonGroup`s to render standard buttons
instead of radio buttons under the hood, per recent a11y recommendations
([#7325](elastic/eui#7325))
- `EuiAccordion` now defaults to a less screenreader-noisy `group` role
instead of `region`. If your accordion contains significant enough
content to be a document landmark role, you may re-configure it back to
`region`. ([#7326](elastic/eui#7326))
- Reduced screen reader noisiness when sorting `EuiDataGrid` columns via
toolbar ([#7327](elastic/eui#7327))
- `EuiGlobalToastList` now defaults to a `log` role. If your toasts will
always require immediate user action, consider (with caution) using the
`alert` role instead.
([#7328](elastic/eui#7328))

**CSS-in-JS conversions**

- Updated `$euiFontFamily` and `$euiCodeFontFamily` to match Emotion
fonts ([#7332](elastic/eui#7332))

---------

Co-authored-by: Cee Chen <constance.chen@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Cee Chen <549407+cee-chen@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants