Summary:
Introduced a highlight manager, which prevents drilling the highlight through the entire component tree and causing too many re-renders.
Also smartly optimizes that non-matched highlighted text doesn't render unnecessarily, and debounces the updates.
Finally, automatically scroll to the first highlight.
Reviewed By: jknoxville
Differential Revision: D21348575
fbshipit-source-id: 71f7ba2e981ad3fc1ea7f5e7043645e6b6811fb7
Summary: This diff refactors the group selection to the dropdown. As with the growing list of grps, dropdown will be easy to search and scale
Reviewed By: mweststrate
Differential Revision: D21175998
fbshipit-source-id: 90f1a81dfc6c2232cd2dcf767ed01205fc63e1fd
Summary: a bit of refactoring since we are going to use elements inspector a lot in NT related plugins
Reviewed By: jknoxville
Differential Revision: D21155830
fbshipit-source-id: 0ff6acf97658bccbbed86388257bbad207fd65b4
Summary:
This diff introduces a Layout component.
Layout is now quite randomly build up by using panels, sidebars, flex columns, flexrow and view components. They all have slight different scrolling, overflow, and grow behavior. Which causes issues with areas not being srcollable, double scrollbars or simply the wrong area scrolling. Too make things worse to design, many components by default display hidden content, and show scrollbars automatically rather than deliberately.
To work towards a consist, and especially simple layout model, over time I want to build a consistent outside-in layout model, where always parents reserve space for children, and children fill the available space and device it even further.
Note that this approaches better how 'applications' typically organize their layout, which is opposite from the classic 'document', where the contents is allowed to grow and is used to push things down / aside where they want. However, such a model fits an application with toolbars, sidebars and scroll regions badly, and currently those two philosophies are mixed throughout the application.
This component is a very small first step to organizing our layout consistently. By using a new component there is less risk to break existing layouts. The `Layout` component takes up all available space, both horizontally and vertically, and gives the first child what it needs based on its own size (typically, a toolbar or (resizable) sidebar), and all the remaining space to the second child. By default the space is distributed vertically, but it can also be distributed horizontally. It can provide scrollbars as well if needed so that the main content doesn't need to provide that by itself.
Examples:
```
<Layout scrollable>
<Toolbar />
<LargePicture />
</Layout>
<Layout horizontal>
<ResizableSidebar />
<SomeContentTable />
</Layout>
```
Reviewed By: jknoxville
Differential Revision: D21178245
fbshipit-source-id: c2d2f167d1572278e51a5b66e1cbf13c42c3b898
Summary: there are two plugins which uses copy-pasted ToolbarIcon and at least one more where it will be helpful. Let's move it to components folder
Reviewed By: nikoant
Differential Revision: D21089290
fbshipit-source-id: a14dcd56633dd24016711e34308b94023fcb40ed
Summary:
1) moved "sonar/desktop/src" to "sonar/desktop/app/src", so "app" is now a separate package containing the core Flipper app code
2) Configured yarn workspaces with the root in "sonar/desktop": app, static, pkg, doctor, headless-tests. Plugins are not included for now, I plan to do this later.
Reviewed By: jknoxville
Differential Revision: D20535782
fbshipit-source-id: 600b2301960f37c7d72166e0d04eba462bec9fc1
