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

docs/extending/create-plugin.mdx

@@ -9,7 +9,7 @@ import {FbInternalOnly, OssOnly} from 'internaldocs-fb-helpers';
 
 ## FlipperPlugin
 
-The plugin implementation that runs on the (mobile) application side of things is called the _client plugin_ in Flipper terminology. 
+The plugin implementation that runs on the (mobile) application side of things is called the _client plugin_ in Flipper terminology.
 To build a client plugin, implement the `FlipperPlugin` interface.
 
 The ID that is returned from your implementation needs to match the `name` defined in your JavaScript counterpart's `package.json`.
@@ -47,7 +47,7 @@ public class MyFlipperPlugin implements FlipperPlugin {
 </TabItem>
 <TabItem value="ios">
 
-```objective-c
+```objc
 @interface MyFlipperPlugin : NSObject<FlipperPlugin>
 @end
 
@@ -127,7 +127,7 @@ connection.receive("getData", new FlipperReceiver() {
 </TabItem>
 <TabItem value="ios">
 
-```objective-c
+```objc
 @interface MyFlipperPlugin : NSObject<FlipperPlugin>
 @end
 
@@ -204,7 +204,7 @@ connection.send("MyMessage",
 </TabItem>
 <TabItem value="ios">
 
-```objective-c
+```objc
 [connection send:@"getData" withParams:@{@"message":@"hello"}];
 ```
 
@@ -275,7 +275,7 @@ if (client != null) {
 </TabItem>
 <TabItem value="ios">
 
-```objective-c
+```objc
 FlipperClient *client = [FlipperClient sharedClient];
 MyFlipperPlugin *myPlugin = [client pluginWithIdentifier:@"MyFlipperPlugin"];
 [myPlugin sendData:myData];

docs/extending/create-table-plugin.mdx

@@ -18,7 +18,7 @@ Below is a sample implementation of a desktop plugin based on `createTablePlugin
 
 See "[Create Plugin](create-plugin)" for how to create the native counterpart for your plugin.
 
-```javascript
+```tsx
 import {ManagedDataInspector, Panel, Text, createTablePlugin} from 'flipper';
 
 type Id = string;

docs/extending/desktop-plugin-structure.mdx

@@ -122,7 +122,7 @@ Flipper Desktop plugins come in three possible flavors:
 
 A plugin always exposes two elements from its entry module (typically `src/index.tsx`): `plugin` and `Component`:
 
-```typescript
+```tsx
 import {PluginClient} from 'flipper-plugin';
 
 export function plugin(client: PluginClient) {
@@ -143,7 +143,7 @@ Flipper also supports so-called device plugins - plugins that are available for
 so are a bit more limited in general.
 Their entry module anatomy is:
 
-```typescript
+```tsx
 import {DevicePluginClient} from 'flipper-plugin';
 
 export function devicePlugin(client: DevicePluginClient) {

docs/extending/establishing-a-connection.mdx

@@ -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.
 

docs/extending/new-clients.mdx

@@ -58,7 +58,7 @@ The syntax used for these type definitions is [Flow](https://flow.org/en/docs/ty
 ### getPlugins
 Return the available plugins as a list of identifiers. A plugin identifier is a string which is matched with the plugin identifier of desktop javascript plugins. This allows the client to specify the plugins it supports.
 
-```
+```js
 Request = {
   "method": "getPlugins",
 }
@@ -75,7 +75,7 @@ Response = {
 
 Returns a subset of the available plugins returned by `getPlugin`. The background connections will automatically receive a connection from Flipper once it starts (and if the plugins are enabled), rather than waiting for the user to open the plugin.
 
-```
+```js
 Request = {
   "method": "getBackgroundPlugins",
 }
@@ -89,7 +89,7 @@ Response = {
 
 ### init
 Initialize a plugin. This should result in an onConnected call on the appropriate plugin. Plugins should by nature be lazy and should not be initialized up front as this may incur significant cost. The Flipper desktop client knows when a plugin is needed and should control when to initialize them.
-```
+```js
 Request = {
   "method": "init",
   "params": {
@@ -100,7 +100,7 @@ Request = {
 
 ### deinit
 Opposite of init. A call to deinit is made when a plugin is no longer needed and should release any resources. Don't rely only on deinit to release plugin resources as Flipper may quit without having the chance to issue a deinit call. In those cases, you should also rely on the RSocket disconnect callbacks. This call is mainly for allowing the desktop app to control the lifecycle of plugins.
-```
+```js
 Request = {
   "method": "deinit",
   "params": {
@@ -115,7 +115,7 @@ request.params.api is the plugin id.
 request.params.method is the method within the plugin to execute.
 request.params.params is an optional params object containing the parameters to the RPC invocation.
 
-```
+```js
 Request = {
   "method": "execute",
   "params": {
@@ -137,7 +137,7 @@ Response = {
 The Flipper desktop app handles error reporting so you don't have to. If an error occurs during the execution of an RPC invocation, return a serialization of it in the response so it can be attributed to the method call.
 
 If an error occurs in some other context, you can proactively send it to Flipper with the following request structure:
-```
+```js
 Request = {
   error: {
     message: string,
@@ -150,7 +150,7 @@ While in development mode, Flipper will display any client errors next to javasc
 ## Testing
 Testing is incredibly important when building core infrastructure and tools. The following is pseudo code for tests we would expect any new FlipperClient implementation to implement and correctly execute. To run tests we strongly encourage you to build a mock for the RSocket connection to mock out the desktop side of the protocol and to not have any network dependencies in your test code.
 
-```
+```js
 test("GetPlugins", {
   let connection = new MockConnection();
   let client = new FlipperClient(connection);
@@ -172,7 +172,7 @@ test("GetPlugins", {
   }));
 });
 ```
-```
+```js
 test("InitDeinit", {
   let connection = new MockConnection();
   let client = new FlipperClient(connection);
@@ -204,7 +204,7 @@ test("InitDeinit", {
   assertFalse(plugin.connected);
 });
 ```
-```
+```js
 test("Disconnect", {
   let connection = new MockConnection();
   let client = new FlipperClient(connection);
@@ -228,7 +228,7 @@ test("Disconnect", {
   assertFalse(plugin.connected);
 });
 ```
-```
+```js
 test("Execute", {
   let connection = new MockConnection();
   let client = new FlipperClient(connection);

docs/extending/plugin-distribution.mdx

@@ -13,7 +13,7 @@ Flipper plugins are essentially standard npm packages. So you can publish them b
 
 1. `package.json` and code [must follow the Flipper plugin specification](desktop-plugin-structure#plugin-definition)
 2. code must be bundled using "flipper-pkg" before packing or publishing. This can be done by executing `flipper-pkg bundle` on `prepack` step:
-    ```
+    ```json
     {
       ...
       "devDependencies": {

docs/extending/search-and-filter.mdx

@@ -31,7 +31,7 @@ The list of filters that are currently applied.
 
 
 ### Example
-```
+```tsx
 import type {SearchableProps} from 'flipper';
 import {Searchable} from 'flipper';
 

docs/extending/styling-components.mdx

@@ -10,17 +10,17 @@ Flipper ships with its own design system which is based on [Ant Design](https://
 In general, custom styling should be needed rarily, as Ant Design provides a very extensive set of [components](https://ant.design/components/overview/).
 
 To build plugin layout and data visualization Flipper ships with an additional set of components through the `flipper-plugin` package.
-The list of available additional compoents can be found in the <Link to={useBaseUrl('/docs/extending/flipper-plugin#ui-components')}>API Reference</Link> and are further documented 
+The list of available additional components can be found in the <Link to={useBaseUrl('/docs/extending/flipper-plugin#ui-components')}>API Reference</Link> and are further documented
 in the Flipper Style Guide which can be found in Flipper under `View > Flipper style guide`.
 
-In case you still need customly styled components, 
+In case you still need customly styled components,
 we are using [emotion](https://emotion.sh) to style our components. For more details on how this works, please refer to emotion's documentation. We heavily use their [Styled Components](https://emotion.sh/docs/styled) approach, which allows you to extend our and Ant's built-in components.
 
 ## Basic tags
 
 For basic building blocks (views, texts, ...) you can use the styled object.
 
-```javascript
+```js
 import {styled} from 'flipper-plugin';
 
 const MyView = styled.div({
@@ -34,10 +34,10 @@ const MyInput = styled.input({ ... });
 
 ## Extending Flipper Components
 
-In some cases it is required to customize Ant or Flipper's components in some way. For example changing colors, alignment, or wrapping behavior. 
+In some cases it is required to customize Ant or Flipper's components in some way. For example changing colors, alignment, or wrapping behavior.
 Flippers components can be wrapped using the `styled` function which allows adding or overwriting existing style rules.
 
-```javascript
+```jsx
 import {Layout, styled} from 'flipper-plugin';
 
 const Container = styled(Layout.Container)({
@@ -55,7 +55,7 @@ The CSS-in-JS object passed to the styled components takes just any CSS rule, wi
 
 The style object can also be returned from a function for dynamic values. Props can be passed to the styled component using React.
 
-```javascript
+```jsx
 const MyView = styled.div(
   props => ({
     fontSize: 10,
@@ -81,7 +81,7 @@ Children can be matched by using normal CSS selectors. This makes it possible to
 
 ## Colors
 
-The `theme` module contains all standard colors used by Flipper. All available colors can be previewed by starting Flipper and opening `View > Flipper Style Guide`. 
+The `theme` module contains all standard colors used by Flipper. All available colors can be previewed by starting Flipper and opening `View > Flipper Style Guide`.
 The colors exposed here will handle dark mode automatically, so it is recommended to use those colors over hardcoded ones.
 
 ```javascript

docs/extending/supporting-layout.mdx

@@ -8,7 +8,7 @@ To enable the Flipper layout inspector on a new platform, just implement a clien
 Note that we're using [Flow](https://flow.org/en/docs/types/objects/) syntax to specify this JSON API.
 
 ### Node
-```
+```ts
 type NodeId = string;
 
 type InspectorValue = {
@@ -45,7 +45,7 @@ InspectorValue can also be used to change the parsed type of the value, such as
 
 ### Plugin Interface
 
-```
+```ts
 interface ClientLayoutPlugin {
   Node getRoot();
   GetNodesResponse getNodes({ids: Array<NodeId>});

docs/extending/testing.mdx

@@ -16,9 +16,9 @@ Developer tools are only used if they work. We have built APIs to test plugins.
 
 Flipper uses [Jest](https://jestjs.io/) as unit testing framework.
 
-Writing unit tests for Flipper Desktop plugins is covered in detail in the [tutorial](../../docs/tutorial/js-custom#testing-plugin-logic). 
+Writing unit tests for Flipper Desktop plugins is covered in detail in the [tutorial](../../docs/tutorial/js-custom#testing-plugin-logic).
 
-The `flipper-plugin` package provide several [test utilities](../../docs/extending/flipper-plugin#testutils) to make testing more convenient. 
+The `flipper-plugin` package provide several [test utilities](../../docs/extending/flipper-plugin#testutils) to make testing more convenient.
 
 ## Client plugins
 
@@ -76,7 +76,7 @@ public void myTest() {
 
 Start by creating your first test file in this directory `MyFlipperPluginTests.cpp` and import the testing utilities from `fbsource//xplat/sonar/xplat:FlipperTestLib`. These utilities mock out core pieces of the communication channel so that you can test your plugin in isolation.
 
-```
+```objc
 #include <MyFlipperPlugin/MyFlipperPlugin.h>
 #include <FlipperTestLib/FlipperConnectionMock.h>
 #include <FlipperTestLib/FlipperResponderMock.h>
@@ -99,7 +99,7 @@ TEST(MyFlipperPluginTests, testDummy) {
 
 Here is a simple test using these mock utilities to create a plugin, send some data, and assert that the result is as expected.
 
-```
+```objc
 TEST(MyFlipperPluginTests, testDummy) {
   std::vector<folly::dynamic> successfulResponses;
   auto responder = std::make_unique<FlipperResponderMock>(&successfulResponses);