Summary:
Tried to give as much context here not just for how it works but also
how to set it up. For other projects and if we need to redo something.
Reviewed By: mweststrate
Differential Revision: D26400452
fbshipit-source-id: 9b41fd1a36c45554c7a7b562b73b4b9753f7ecfe
Summary: Still need to update the actual release doc. That's next.
Reviewed By: mweststrate
Differential Revision: D26399883
fbshipit-source-id: 87c27b254f4def07810a99fd0e1c817b6afb967e
Summary:
Introduced `isConnected` flag on device and plugin client to reflect whether a connection is still available for the plugins, or that they have been disconnected.
Potentially we could expose the (readonly) `connected` state atom for this as well, or an `onDisconnect` event for device pugins, to create a responsive UI, but there might be no need for that, in which case this suffices.
Reviewed By: nikoant
Differential Revision: D26249346
fbshipit-source-id: b8486713fdf2fcd520488ce54f771bd038fd13f8
Summary:
Unlike non-sandy plugins, non-sandy plugins weren't serialized using our serialization utility yet. This diff addresses that, meaning that users don't have to bother about how to serialize maps, sets and dates.
Unlike the old fashioned plugins, the `makeObjectSerialize` utility is used, rather than `serialize`. This normalizes the objects, but doesn't serialize them, which is done at the end of the export data process anyway for the whole tree. This avoids creating a double JSON serialization which is fully of ugly escape characters.
This makes the onImport / onExport definition of the logs plugin nicer.
Also improved the docs.
Reviewed By: nikoant
Differential Revision: D26146421
fbshipit-source-id: 6abfb6ee2e3312e2a13a11832ff103dc62fd844c
Summary: Per title, this allows for pre-processing data after it is deserialized and before it is stored in the plugin
Reviewed By: nikoant
Differential Revision: D26126423
fbshipit-source-id: bc08a6ab205d2a0d551515563cd85a197595ddb2
Summary:
Sandy plugins can now set up an `onExport` handler to enable customizing the export format of a plugin: `client.onExport(callback: (idler, onStatusMessage) => Promise<state>)`
Import will be done in next diff
Reviewed By: nikoant
Differential Revision: D26124440
fbshipit-source-id: c787c79d929aa8fb484f15a9340d7c87545793cb
Summary:
Used this to find out that my 0.10 release was borked but this one works.
This doesn't require any code changes because we're already using the
equivalent of 0.10.1 internally through the mono repo.
Changelog: Update to SoLoader 0.10.1
Reviewed By: nikoant
Differential Revision: D26148652
fbshipit-source-id: 7d8c2bc8d8dfaca7118d240bd365be08948e4623
Summary: This diff adds the `--public-build` option which allows run a devServer emulating the OSS version of flipper. Technical details are explained in the comments.
Reviewed By: passy, nikoant
Differential Revision: D25944966
fbshipit-source-id: 540855808179582752b8aa646f0b8afd4b78396f
Summary:
The redirects we added inline in the deleted pages don't work when there's a baseUrl.
This is because it's the standard react-router Redirect component, which knows nothing about docusaurus sites.
We could get around that by adding `useBaseUrl()` calls around all of them, but that's not great.
So changing to using declarative redirects instead, where they are all put in config. This automatically takes care of base urls, and reduces copy-pasted code.
Reviewed By: passy
Differential Revision: D25780599
fbshipit-source-id: c67d3643ab28f0fcd440904baf54c67687781686
Summary:
Give the sdk installation pages a bit more structure.
To me it's much clearer now what they are.
Happy to hear differing opinions so we get it right :)
Reviewed By: passy
Differential Revision: D25638164
fbshipit-source-id: 86b7fecd8aba0068336b15a308f4a9433817c68e
Summary:
The installation instructions didn't flow very well.
"Using flipper at Facebook" is now gone. It's installation steps have been moved into the desktop app page, with internal/external switching.
I've also removed the "Updating Flipper" internal page, and put equivalent info in the installation section.
Reviewed By: nikoant
Differential Revision: D25637831
fbshipit-source-id: 2af2abf57793d54804f5c45e3335b8641743e1c8
Summary:
I think there's a need for an "implementation details" section of the site. Especially as we're moving the rest of our wiki content there.
I see it as a good thing, because now we have a place for implementation details relevant to OSS contributors too, it's not all fb-specific.
Reviewed By: nikoant
Differential Revision: D25614909
fbshipit-source-id: 5ec081e6450a9ad1c30785ae4cca74b6fa0d2630
Summary: This diff unifies setup and workflow information that was scattered a bit around into one cohesive 'Development workflow' subsection in the 'creating plugins' section of Flipper.
Reviewed By: nikoant
Differential Revision: D25612288
fbshipit-source-id: 5fa7f2d000fb7ab3e1b5c5a4fc8cc1f209252f41
Summary: There were 3 pages describing how to obtain a plugin instance, public, ios and android. iOS didn't differ from the public one, and android only in the fact that internally DI is available. So combined the pages with just an optional section for DI inside FB on Android.
Reviewed By: jknoxville
Differential Revision: D25588057
fbshipit-source-id: 3a54ae699130a4c5ba018220708f844a35a8d6a9
Summary: There was one public page for testing client plugins, and two internal ones. Combined it into a one pager, that has tabs per target, with separate content for internal versus external (didn't combine those as the testing frameworks recommended differ)
Reviewed By: nikoant
Differential Revision: D25588058
fbshipit-source-id: afa151ec0c3a5de26142938d3d389627716f1ff7
Summary: send data was documented twice, in the general client API, and in the internal docs where it was specifically combined with obtaining a plugin instance. However, that is a proper public API as well, so combined those two.
Reviewed By: nikoant
Differential Revision: D25588059
fbshipit-source-id: 7135a74b64a87d0c8c3f8f20f7f260469f52d41c
Summary:
Previously we used <Link/> everywhere with useBaseUrl to avoid link destinations depending on the current url of the page.
This isn't necessary if you instead link to the **file name**, rather than the **url path**.
Then the links are resolved at build time, and work across imported markdown files etc.
This diff just does the pages under Features, because other ones will get conflicts. I'll do those later.
Reviewed By: nikoant
Differential Revision: D25589707
fbshipit-source-id: 35ca986e19fc2af1054b81d7253eeb3827947ab8
Summary: Seems that all tabs were broken after migration to Docusaurus 2.
Reviewed By: jknoxville
Differential Revision: D25586214
fbshipit-source-id: 31a8da4e13fbac01911a03f1f4bab0d2837c9c9a
Summary:
This diff restructures the 'extending' section of the docs, and rebrands it to 'creating plugins'. It then restructures this section into 4 top-level items
* Tutorial
* Desktop plugin APIs
* Client plugin APIs
* Workflow
Pages are put under the relevant sections, including pages which were before under internal. Some pages that didn't relate directly to plugin development have been moved to other top level sections (e.g. testing RN).
I didn't do de-duplication between pages yet, that will be done in the next diff.
Overview of changes:
* Extending -> Creating Plugins
* Moved Extending > Other platforms to Setup > Other platforms (as this is about clients, not plugins)
* Moved Internal FB plugin development stuff into Creating Plugins
* Separated Creating Plugins into ‘Tutorial’, Desktop API Reference, Cient API Reference, Workflow
* Remove TypeScript strict page, we are already strict
* Moved QPL linters to api docs and named id QPL lints
* Grouped the different pages on extending Layout plugin (needs deduping still)
* Warning about avoiding custom styling in general
* Moved internal index page to the top of the navigation of FB Internal, rather than at the bottom
Reviewed By: passy
Differential Revision: D25585172
fbshipit-source-id: ba2aa891395097d6aa101809084b915f115ee69d
Summary:
Now in public, the setup page remains unchanged, well, the headings are one level smaller.
In internal, the page is divided into two sections: for buck based apps, and non-buck based ones.
Reviewed By: mweststrate
Differential Revision: D25565953
fbshipit-source-id: abf4316a28970cd93d0cc9b56dd707f00a674a48
Summary:
Putting both iOS setup guides next to each other.
I'm not sure what to call the oss one. It applies to cocoapods, swift, and pure objc.
Reviewed By: passy
Differential Revision: D25563988
fbshipit-source-id: a7ee2a0ae04e5753a74939b1c170d9a2f2ace1a9
Summary: Puts both the "Adding flipper to android apps" page next to each other, one for buck and one for gradle. The buck one is only internal.
Reviewed By: passy
Differential Revision: D25563688
fbshipit-source-id: 1937cfdd0d5129b54a8635efe6294ba39a26be8e
Summary: The 'extending flipper' introduction page didn't contain anything meaty, so collapsed it into the tutorial introduction, cleaning up the top level navigation.
Reviewed By: passy
Differential Revision: D25531718
fbshipit-source-id: ca0f98186e889e13cb97be8818db3588738e5039
Summary:
Introduced API to replace the deprecated `selectPlugin` in Sandy.
The API can be used to navigate from `device plugin -> device plugin`, or` client plugin -> device / client plugin`
Introduced `isPluginAvailable` as well, so that the user interaction an be fine tuned in case the plugin is not disabled.
Reviewed By: jknoxville
Differential Revision: D25422370
fbshipit-source-id: c6c603f1c68e6291280b3d0883e474448754ded1
Summary: When exposing new top-level APIs from `flipper-plugin`, they should be documented. Added a unit test to enforce this and added documentation for all missing APIs.
Reviewed By: passy
Differential Revision: D25421401
fbshipit-source-id: f5cafc1881de846c8a5dd86e5d094ebd27a66f2a
Summary: In the Flipper chrome there is a lot of `logger={logger}` prop drilling. Let's not do that anymore in the future by using a proper hook, which is exposed from `flipper-plugin`.
Reviewed By: passy
Differential Revision: D25421304
fbshipit-source-id: 01ec8563c67f7e2fac359c2f8216eba722bff8d9
Summary:
This replaces the existing "FB Internals" troubleshooting" page with a redirect to the now single troubleshooting page, to make sure no links break.
It copies the content of that internal page into an internal-troubleshooting.mdx file, that isn't in any sidebars.
And it gets the main troubleshooting page to include that page, when doing an internal build. So now we only have one troubleshooting page.
Reviewed By: passy
Differential Revision: D25372552
fbshipit-source-id: 1a310ca1a4a21683d6074d480e819e5af40c8af2
