jens/flipper
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix several links

Browse Source 
Summary: Per discussion in parent diff, fixed the links to be idiomatic so that they work in both internal and public builds

Reviewed By: jknoxville

Differential Revision: D27963896

fbshipit-source-id: 35504b04e8975acc419be668804c5d7ad7aa2a16
This commit is contained in:
Michel Weststrate
2021-04-23 04:13:28 -07:00
committed by Facebook GitHub Bot
parent 3af41bfdd1
commit 0e08b63ce3
4 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/extending/flipper-plugin.mdx
View File

@@ -8,7 +8,7 @@ title: Desktop Plugin API
`PluginClient` is the type of the `client` passed into a standard Sandy plugin. `PluginClient` is the type of the `client` passed into a standard Sandy plugin.
It takes two generic arguments `Event` and `Methods`. It takes two generic arguments `Event` and `Methods`.
* The `Event` generic is a mapping of an event name to the data structure of the payload, as explained [here](../tutorial/js-custom#the-plugin-declaration). * The `Event` generic is a mapping of an event name to the data structure of the payload, as explained [here](../tutorial/js-custom.mdx#the-plugin-declaration).
* The `Methods` generic is used to describe the methods that are offered by the plugin implementation on the device. `Methods` is a mapping of a method name to a function that describes the signature of a method. The first argument of that function describes the parameters that can be passed to the client. The return type of the function should describe what is returned from the client. Wrapped with a `Promise`. * The `Methods` generic is used to describe the methods that are offered by the plugin implementation on the device. `Methods` is a mapping of a method name to a function that describes the signature of a method. The first argument of that function describes the parameters that can be passed to the client. The return type of the function should describe what is returned from the client. Wrapped with a `Promise`.
Quick example on how those generics should be used: Quick example on how those generics should be used:

2
docs/extending/js-plugin-api.mdx
View File

@@ -9,7 +9,7 @@ The APIs shown here are deprecated. The APIs exposed from [`flipper-plugin`](./f
<div class="warning"> <div class="warning">
This page describes the JavaScript API that is used to implement plugins inside the Flipper Desktop application. For the JavaScript API that can be used inside React Native to communicate with the Flipper Desktop, see [Client Plugin API](create-plugin). This page describes the JavaScript API that is used to implement plugins inside the Flipper Desktop application. For the JavaScript API that can be used inside React Native to communicate with the Flipper Desktop, see [Client Plugin API](create-plugin.mdx).
</div> </div>

8
docs/extending/sandy-migration.mdx
View File

@@ -65,7 +65,7 @@ It used to be necessary to use `persistedState` for this kind of state, but that
In contrast, the `Component` component is mounted whenever the user _opens_ the plugin, so any state stored locally in that React component will be lost if the user navigates away. In contrast, the `Component` component is mounted whenever the user _opens_ the plugin, so any state stored locally in that React component will be lost if the user navigates away.
We recommend avoiding that, and store state, including selection, in the `plugin` definition instead, using the `createState` abstraction. We recommend avoiding that, and store state, including selection, in the `plugin` definition instead, using the `createState` abstraction.
The relation between `plugin`, its parameter `client`, and how to use it in your `Component` definition is documented in detail in the [Plugin Declaration section](../tutorial/js-custom#the-plugin-declaration). The relation between `plugin`, its parameter `client`, and how to use it in your `Component` definition is documented in detail in the [Plugin Declaration section](../tutorial/js-custom.mdx#the-plugin-declaration).
Please read it before continuing as it will explain how to manage state, handle receiving and sending data and testing in detail. Please read it before continuing as it will explain how to manage state, handle receiving and sending data and testing in detail.
The full set of available APIs on `client` is documented on the [Desktop Plugin API](flipper-plugin.mdx#pluginclient) page. The full set of available APIs on `client` is documented on the [Desktop Plugin API](flipper-plugin.mdx#pluginclient) page.
@@ -81,7 +81,7 @@ This step is completed if the plugin follows the next `plugin` / `component` str
* These steps typically does not involve change much the UI or touch other files than `index.tsx`. Typically, the root component needs to be changed, but most other components can remain as is. However, if a ManagedTable is used (see the next section), it might be easier to already convert the table in this step. * These steps typically does not involve change much the UI or touch other files than `index.tsx`. Typically, the root component needs to be changed, but most other components can remain as is. However, if a ManagedTable is used (see the next section), it might be easier to already convert the table in this step.
* Sandy has first class support for unit testing your plugin and mocking device interactions. Please do set up unit tests per documentation linked above! * Sandy has first class support for unit testing your plugin and mocking device interactions. Please do set up unit tests per documentation linked above!
* If the original plugin definition contained `state`, it is recommended to create one new state atoms (`createState`) per field in the original `state`, rather than having one big atom. * If the original plugin definition contained `state`, it is recommended to create one new state atoms (`createState`) per field in the original `state`, rather than having one big atom.
* If the original plugin definition contained `persistedState`, it is recommended to create one new state atoms (`createState`) per field in the original `state`, rather than having one big atom. By setting the `persist` [option](flipper-plugin#options) of the state, you can make sure this piece of state becomes part of the import / export functionality of Flipper. Which is important if the data stored here is relevant for bug reports. * If the original plugin definition contained `persistedState`, it is recommended to create one new state atoms (`createState`) per field in the original `state`, rather than having one big atom. By setting the `persist` [option](flipper-plugin.mdx#options) of the state, you can make sure this piece of state becomes part of the import / export functionality of Flipper. Which is important if the data stored here is relevant for bug reports.
* For deeply nested state updates, using `state.update` is often simpler than using `state.set`, as it uses [immer](https://immerjs.github.io/immer/) under the hood to make immutable state updates straight forward. * For deeply nested state updates, using `state.update` is often simpler than using `state.set`, as it uses [immer](https://immerjs.github.io/immer/) under the hood to make immutable state updates straight forward.
* When dealing a lot with promises, using [`async` / `await`](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async_await) is usually simpler. * When dealing a lot with promises, using [`async` / `await`](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async_await) is usually simpler.
* Utilities, like writing text to clipboard or creating pastes, if not exposed from the `client` object, can be typically found in the FlipperLib, for example: `tryGetFlipperLibImplementation()?.writeTextToClipboard(text)`. * Utilities, like writing text to clipboard or creating pastes, if not exposed from the `client` object, can be typically found in the FlipperLib, for example: `tryGetFlipperLibImplementation()?.writeTextToClipboard(text)`.
@@ -117,7 +117,7 @@ There are three important resources to check for documentation on the components
1. If you start Flipper, and go to `View > Flipper style guide`, you will see a general overview of the Flipper design system. It will demonstrate colors, typography and creating layouts including some examples. 1. If you start Flipper, and go to `View > Flipper style guide`, you will see a general overview of the Flipper design system. It will demonstrate colors, typography and creating layouts including some examples.
2. The [ant.design component overview](https://ant.design/components/overview/) 2. The [ant.design component overview](https://ant.design/components/overview/)
3. The [API reference](flipper-plugin#ui-components) documentation for the components provided by `flipper-plugin` 3. The [API reference](flipper-plugin.mdx#ui-components) documentation for the components provided by `flipper-plugin`
### Old and new components ### Old and new components
@@ -134,7 +134,7 @@ For conversion, the following table maps the old components to the new ones:
| `Text` / `Heading` | `Typography.Text` / `Typography.Heading` | `antd` || | `Text` / `Heading` | `Typography.Text` / `Typography.Heading` | `antd` ||
| `Button` | `Button` | `antd` || | `Button` | `Button` | `antd` ||
| `Glyph` | `Icon` | `antd` || | `Glyph` | `Icon` | `antd` ||
| `ManagedDataTable` | `DataTable` | `flipper-plugin` | Requires state to be provided by a [`createDataSource`](flipper-plugin#createdatasource) | | `ManagedDataTable` | `DataTable` | `flipper-plugin` | Requires state to be provided by a [`createDataSource`](flipper-plugin.mdx#createdatasource) |
| `ManagedDataInspector` / `DataInspector` | `DataInspector` | `flipper-plugin` || | `ManagedDataInspector` / `DataInspector` | `DataInspector` | `flipper-plugin` ||
| `ManagedElementInspector` / `ElementInspector` | `ElementInspector` | `flipper-plugin` || | `ManagedElementInspector` / `ElementInspector` | `ElementInspector` | `flipper-plugin` ||

2
docs/tutorial/js-custom.mdx
View File

@@ -166,7 +166,7 @@ Using `TestUtils.startPlugin` (`(3)`) we can instantiate our plugin in a fully m
in which our plugin can do everything except for actually rendering, which makes this operation really cheap. in which our plugin can do everything except for actually rendering, which makes this operation really cheap.
From the `startPlugin`, we get back an `instance`, which corresponds to the object we returned from our `plugin` implementation (`(4)` in our previous listing). From the `startPlugin`, we get back an `instance`, which corresponds to the object we returned from our `plugin` implementation (`(4)` in our previous listing).
Beyond that, we get a bunch of utilities to interact with our plugin. Beyond that, we get a bunch of utilities to interact with our plugin.
The full list is documented [here](../extending/flipper-plugin#the-test-runner-object), but for this test we are only interested in `sendEvent`. The full list is documented [here](../extending/flipper-plugin.mdx#the-test-runner-object), but for this test we are only interested in `sendEvent`.
Using `sendEvent`, we can mimic the client plugin sending events to our plugin `(4)`. Using `sendEvent`, we can mimic the client plugin sending events to our plugin `(4)`.
Similarly we can emulate all other possible events, such as the initial connection setup with (`.connect()`), the user (de)selecting the plugin (`.activate()` / `deactivate()`), or a deeplink being triggered (`.triggerDeepLink`) etc. Similarly we can emulate all other possible events, such as the initial connection setup with (`.connect()`), the user (de)selecting the plugin (`.activate()` / `deactivate()`), or a deeplink being triggered (`.triggerDeepLink`) etc.