improve docs code blocks highlighting (#2049)

Summary:
This PR adds missing Objective-C entry to the Docusaurus config, fixes Objective-C code blocks label and adds or replaces several code block labels to improve the currently highlighted blocks.

Prism in Docusaurus by default also includes syntax highlight for `jsx` and `tsx`, which improves the nodes and props highlight, so I have used those syntaxes in few places too.

I have also fixed one typo that I have spotted and my IDE made a cleanup of whitespaces in edited files.

## Changelog

* [website] improve docs code blocks highlighting

Pull Request resolved: https://github.com/facebook/flipper/pull/2049

Test Plan:
The changes have been tested running Flipper website on `localhost`.

## Preview

<img width="650" alt="Screenshot 2021-03-12 150934" src="https://user-images.githubusercontent.com/719641/110951135-fff20d00-8344-11eb-96db-1bdc82c8d5ea.png">

<img width="649" alt="Screenshot 2021-03-12 151022" src="https://user-images.githubusercontent.com/719641/110951268-2ca62480-8345-11eb-9d3b-1a48f1267776.png">

Reviewed By: priteshrnandgaonkar

Differential Revision: D27336599

Pulled By: passy

fbshipit-source-id: c2dfb3d8cad4675da0f5e1270cada1e56a0175c0
This commit is contained in:
Bartosz Kaszubowski
2021-03-29 02:45:09 -07:00
committed by Facebook GitHub Bot
parent e4a814502a
commit 40e6cdebb1
18 changed files with 83 additions and 83 deletions

View File

@@ -49,7 +49,7 @@ localhost:8089/sonar?os={OS}
```
On that connection, send the following payload:
```
```js
Request = {
"method": "signCertificate",
"csr": string,
@@ -59,13 +59,13 @@ Request = {
```
Where `csr` is a Certificate Signing Request the client has generated, and `destination` identifies a location accessible to both the client and Flipper desktop, where the certificate should be placed.
The Subject Common Name (CN=...) must be included in the CSR, and your `CertificateProvider` implementation in Flipper may use this in combination with the `destination` to determine where to put the certificate.
The Subject Common Name (CN=...) must be included in the CSR, and your `CertificateProvider` implementation in Flipper may use this in combination with the `destination` to determine where to put the certificate.
This will ask Flipper desktop to generate a client certificate, using the CSR provided, and put it into the specified `destination`.
Depending on the client, `destination` can have a different meaning. A basic example would be a file path, that both the desktop and the client have access to. With this Flipper desktop could write the certificate to that path. A more involved example is that of the Android Client, where destination specifies a relative path inside an app container. And the Subject Common Name determines which app container. Together these two pieces of information form an absolute file path inside an android device.
For Flipper desktop to work with a given Client type, it needs to be modified to know how to correctly interpret the `destination` argument, and deploy certificates to it.
For Flipper desktop to work with a given Client type, it needs to be modified to know how to correctly interpret the `destination` argument, and deploy certificates to it.
`destination` field may not be relevant if your `medium` value is more than 1. `medium=1`(default) means Flipper should do certificate exchange by directly putting certificates at `destination` in the sandbox of the app. `medium=2` means Flipper will use Certificate Uploader and Provider to upload certificates and download it on the client side respectively.