Use code switcher instead of tabs

dennisreimann · dennisreimann · commit 75879be43a21 · 2022-07-15T12:22:26.000+02:00
diff --git a/docs/blockchain_data/block_source.md b/docs/blockchain_data/block_source.md
@@ -1,10 +1,11 @@
-# Block Source   
+# Block Source
 
 Implementing the `BlockSource` interface requires defining methods for fetching
 headers, blocks, and the best block hash.
 
-:::: tabs
-::: tab "Rust"
+
+<CodeSwitcher :languages="{rust:'Rust'}">
+  <template v-slot:rust>
 
 ```rust
 impl BlockSource for Blockchain {
@@ -22,10 +23,13 @@ impl BlockSource for Blockchain {
 }
 ```
 
+  </template>
+</CodeSwitcher>
+
 <!-- ADD JAVA EXAMPLE -->
 
 For instance, you may implement this interface by querying Bitcoin Core's JSON
 RPC interface, which happens to be a sample implementation provided by
 `lightning-block-sync`.
 
-Let's walk through the use case where LDK receives full blocks.
+Let's walk through the use case where LDK receives full blocks.
diff --git a/docs/blockchain_data/pre_filtered_blocks.md b/docs/blockchain_data/pre_filtered_blocks.md
@@ -12,8 +12,8 @@ if a block contains relevant transactions before fetching it.
 So how does this work in practice? `ChainMonitor` is parameterized by an
 optional type that implements `chain::Filter`:
 
-:::: tabs
-::: tab "Rust"
+<CodeSwitcher :languages="{rust:'Rust', java:'Java'}">
+  <template v-slot:rust>
 
 ```rust
 impl chain::Filter for Blockchain {
@@ -32,8 +32,8 @@ impl chain::Filter for Blockchain {
 }
 ```
 
-:::
-::: tab "Java"
+  </template>
+  <template v-slot:java>
 
 ```java
 Filter tx_filter = Filter.new_impl(new Filter.FilterInterface() {
@@ -54,11 +54,11 @@ Filter tx_filter = Filter.new_impl(new Filter.FilterInterface() {
 });
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
 
 When this is provided, `ChainMonitor` will call back to the filter as channels
 are opened and blocks connected. This gives the opportunity for the source to
 pre-filter blocks as desired.
 
-Regardless, when a block is connected, its header must be processed by LDK.
+Regardless, when a block is connected, its header must be processed by LDK.
diff --git a/docs/payments/connecting_peers.md b/docs/payments/connecting_peers.md
@@ -6,8 +6,8 @@ of another node that you want as a peer. Once the connection is established and
 the handshake is complete, `PeerManager` will show the peer's pubkey in its list
 of peers.
 
-:::: tabs
-::: tab "Rust"
+<CodeSwitcher :languages="{rust:'Rust', java:'Java'}">
+  <template v-slot:rust>
 
 ```rust
 match lightning_net_tokio::connect_outbound(Arc::clone(&peer_manager), pubkey, address).await {
@@ -33,8 +33,8 @@ match lightning_net_tokio::connect_outbound(Arc::clone(&peer_manager), pubkey, a
 }
 ```
 
-:::
-::: tab "Java"
+  </template>
+  <template v-slot:java>
 
 ```java
 try {
@@ -51,5 +51,5 @@ catch (java.io.IOException e) {
 }
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
diff --git a/docs/payments/managing_channels.md b/docs/payments/managing_channels.md
@@ -17,25 +17,25 @@ Now that you have a peer, you can open a channel with them using
 Channels can be announced to the network or can remain private, which is
 controlled via `UserConfig::announced_channel`.
 
-:::: tabs
-::: tab "Rust"
+<CodeSwitcher :languages="{rust:'Rust', java:'Java'}">
+  <template v-slot:rust>
 
 ```rust
 let amount = 10_000;
 let push_msat = 1_000;
 let user_id = 42;
 let config = UserConfig {
-	channel_options: ChannelConfig { announced_channel: true, ..Default::default() },
-	..Default::default()
+  channel_options: ChannelConfig { announced_channel: true, ..Default::default() },
+  ..Default::default()
 };
 match channel_manager.create_channel(pubkey, amount, push_msat, user_id, Some(config)) {
-	Ok(_) => println!("EVENT: initiated channel with peer {}", pubkey),
-	Err(e) => panic!("ERROR: failed to open channel: {:?}", e),
+  Ok(_) => println!("EVENT: initiated channel with peer {}", pubkey),
+  Err(e) => panic!("ERROR: failed to open channel: {:?}", e),
 }
 ```
 
-:::
-::: tab "Java"
+  </template>
+  <template v-slot:java>
 
 ```java
 long amount = 10_000L;
@@ -49,8 +49,8 @@ Result_NoneAPIErrorZ create_channel_result = channel_manager.create_channel(
 assert create_channel_result instanceof Result_NoneAPIErrorZ.Result_NoneAPIErrorZ_OK;
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
 
 At this point, an outbound channel has been initiated with your peer and it will
 appear in `ChannelManager::list_channels`. However, the channel  is not yet
@@ -59,8 +59,8 @@ funded. Once your peer accepts the channel, you will be notified with a
 funding transaction and pass it to `ChannelManager`, which will broadcast it
 once it receives your channel counterparty's signature.
 
-:::: tabs
-::: tab "Rust"
+<CodeSwitcher :languages="{rust:'Rust', java:'Java'}">
+  <template v-slot:rust>
 
 ```rust
 // In the event handler passed to BackgroundProcessor::start
@@ -99,8 +99,8 @@ match event {
 }
 ```
 
-:::
-::: tab "Java"
+  </template>
+  <template v-slot:java>
 
 ```java
 // After the peer responds with an `accept_channel` message, an
@@ -143,8 +143,8 @@ if (e instanceof Event.FundingGenerationReady) {
 }
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
 
 After `ChannelManager` has broadcast the funding transaction, the channel will
 become usable once the transaction has enough confirmations and will appear in
@@ -162,8 +162,8 @@ unilaterally. The cooperative case makes for lower fees and immediate access to
 funds while the unilateral case does not. The latter may be necessary if your
 peer isn't behaving properly or has gone offline.
 
-:::: tabs
-::: tab "Rust"
+<CodeSwitcher :languages="{rust:'Rust', java:'Java'}">
+  <template v-slot:rust>
 
 ```rust
 let channel_id = channel_manager
@@ -180,8 +180,8 @@ channel_manager.close_channel(&channel_id).expect("ERROR: Failed to close channe
 channel_manager.force_close_channel(&channel_id).expect("ERROR: Failed to close channel");
 ```
 
-:::
-::: tab "Java"
+  </template>
+  <template v-slot:java>
 
 ```java
 // Example: Cooperative close (assuming 1 open channel)
@@ -195,7 +195,7 @@ byte[] channel_id = channel_manager.list_channels()[0].get_channel_id();
 Result_NoneAPIErrorZ channel_manager.force_close_channel(channel_id);
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
 
-Now that we know how to manage channels, let's put our new channel to use!
+Now that we know how to manage channels, let's put our new channel to use!
diff --git a/docs/payments/receiving_payments.md b/docs/payments/receiving_payments.md
@@ -5,8 +5,8 @@ amount and description. `ChannelManager` contains the remaining information
 needed for the invoice. Use the provided utility to generate an invoice and
 register a pending payment in `ChannelManager`.
 
-:::: tabs
-::: tab "Rust"
+<CodeSwitcher :languages="{rust:'Rust', java:'Java'}">
+  <template v-slot:rust>
 
 ```rust
 let amt_msat = 10_000;
@@ -21,8 +21,8 @@ let invoice = match utils::create_invoice_from_channelmanager(
 let encoded_invoice = invoice.to_string();
 ```
 
-:::
-::: tab "Java"
+  </template>
+  <template v-slot:java>
 
 ```java
 String description = "coffee";
@@ -36,8 +36,8 @@ Invoice invoice = ((Result_InvoiceSignOrCreationErrorZ.Result_InvoiceSignOrCreat
 String encoded_invoice = invoice.to_str();
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
 
 While it is possible to create an invoice without using the utility,
 `ChannelManager` will reject any incoming HTLCs for unregistered payments to
@@ -49,8 +49,8 @@ As with sending a payment, LDK will generate an event once a payment is
 received. It is your responsibility to handle the `PaymentReceived` event by
 using `ChannelManager` to release the preimage and claim the funds.
 
-:::: tabs
-::: tab "Rust"
+<CodeSwitcher :languages="{rust:'Rust', java:'Java'}">
+  <template v-slot:rust>
 
 ```rust
 // In the event handler passed to BackgroundProcessor::start
@@ -66,8 +66,8 @@ match event {
 }
 ```
 
-:::
-::: tab "Java"
+  </template>
+  <template v-slot:java>
 
 ```java
 // In the `handle_event` method of ChannelManagerPersister implementation
@@ -80,8 +80,8 @@ else if (e instanceof Event.PaymentReceived) {
 }
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
 
 So there you have it! Those are the basics of using LDK. As you can see, LDK
 offers a ton of flexibility for building Lightning-enabled wallets and apps.
diff --git a/docs/payments/sending_payments.md b/docs/payments/sending_payments.md
@@ -5,8 +5,8 @@ string in accordance with BOLT 11. After parsing the invoice, you'll need to
 find a route from your node to the recipient and then make the payment using
 `ChannelManager`.
 
-:::: tabs
-::: tab "Rust"
+<CodeSwitcher :languages="{rust:'Rust', java:'Java'}">
+  <template v-slot:rust>
 
 ```rust
 // Parse the invoice.
@@ -38,8 +38,8 @@ channel_manager.send_payment(&route, payment_hash, &payment_secret)
 	.expect("ERROR: failed to send payment");
 ```
 
-:::
-::: tab "Java"
+  </template>
+  <template v-slot:java>
 
 ```java
 String invoice_str = // get an invoice from the payee
@@ -73,16 +73,16 @@ if (parsed_invoice instanceof Result_InvoiceNoneZ.Result_InvoiceNoneZ_OK) {
 }
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
 
 An event is generated once a payment has completed. Successful payments result
 in a `PaymentSent` event with the preimage of the payment hash. Be sure to look
 out for a `PaymentFailed` event, if the payment fails for some reason, and act
 accordingly.
 
-:::: tabs
-::: tab "Rust"
+<CodeSwitcher :languages="{rust:'Rust', java:'Java'}">
+  <template v-slot:rust>
 
 ```rust
 // In the event handler passed to BackgroundProcessor::start
@@ -97,8 +97,8 @@ match event {
 }
 ```
 
-:::
-::: tab "Java"
+  </template>
+  <template v-slot:java>
 
 ```java
 // In the `handle_event` method of ChannelManagerPersister implementation
@@ -112,5 +112,5 @@ else if (e instanceof Event.PaymentFailed) {
 }
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
diff --git a/docs/tutorials/build_a_node_in_java.md b/docs/tutorials/build_a_node_in_java.md
@@ -440,8 +440,8 @@ This section assumes you've already run all the steps in [Setup](#setup).
 
 **Example:**
 
-:::: tabs
-::: tab "Java with Full Blocks or BIP 157/158"
+<CodeSwitcher :languages="{java_fullblocks:'Java with Full Blocks or BIP 157/158', java_electrum:'Java with Electrum'}">
+  <template v-slot:java_fullblocks>
 
 ```java
 /* UNCONFIRMED TRANSACTIONS */
@@ -475,8 +475,8 @@ channel_manager.update_best_block(new_best_header, new_best_height);
 chain_monitor.update_best_block(new_best_header, new_best_height);
 ```
 
-:::
-:::tab "Java with Electrum"
+  </template>
+  <template v-slot:java_electrum>
 
 ```java
 // For each connected and disconnected block, and in chain-order, call these
@@ -486,7 +486,7 @@ chain_monitor.update_best_block(new_best_header, new_best_height);
 // Transactions and outputs are registered both on startup and as new relevant
 // transactions/outputs are created.
 
-// header is a []byte type, height is `int`, txdata is a 
+// header is a []byte type, height is `int`, txdata is a
 // TwoTuple_usizeTransactionZ[], where the 0th element is the transaction's
 // position in the block (with the coinbase transaction considered position 0)
 // and the 1st element is the transaction bytes
@@ -497,8 +497,8 @@ channel_manager.as_Listen().block_disconnected(header, height);
 chain_monitor.block_disconnected(header, height);
 ```
 
-:::
-::::
+  </template>
+</CodeSwitcher>
 
 **Implementation notes:**
 * If you're using the `Listen` interface: blocks must be connected and disconnected in chain order
diff --git a/docs/tutorials/build_a_node_in_rust.md b/docs/tutorials/build_a_node_in_rust.md
