fix(docs): revert MDX components for recipes (#3178) (#3343)

This reverts commit 69ac9e0.

docs/content/Auth/AWS-Cognito.md

@@ -19,7 +19,7 @@ If you haven't already created a User Pool, please follow [the instructions in
 the AWS Cognito documentation][link-aws-cognito-hosted-ui] to create one, along
 with enabling the Hosted UI.
 
-### <--{"id" : "Create and configure a User Pool"}--> Custom claims
+### Custom claims
 
 To add custom claims to the JWT, you will need to associate [a Lambda
 function][link-aws-lambda] to the [Pre Token Generation event
@@ -88,7 +88,7 @@ CUBEJS_JWT_CLAIMS_NAMESPACE=<CLAIMS_NAMESPACE>
 
 ## Testing with the Developer Playground
 
-### <--{"id" : "Testing with the Developer Playground"}-->  Retrieving a JWT
+### Retrieving a JWT
 
 Go to the [OpenID Playground from Auth0][link-openid-playground] to and click
 Configuration.
@@ -171,7 +171,7 @@ verify the JWT signature as well as decode the identity token:
   />
 </div>
 
-### <--{"id" : "Testing with the Developer Playground"}-->  Set JWT in Developer Playground
+### Set JWT in Developer Playground
 
 Now open the Developer Playground (at `http://localhost:4000`) and on the Build
 page, click Add Security Context.

docs/content/Auth/Auth0-Guide.md

@@ -49,7 +49,7 @@ Applications.
 Next, go to the application's settings and add the appropriate callback URLs for
 your application (`http://localhost:4000` for the Developer Playground).
 
-### <--{"id" : "Create an application"}-->  Custom claims
+### Custom claims
 
 You can also configure custom claims for your JWT token. Auth0 has two SDKs
 available; [Auth0.js][link-auth0-js] and the [Auth0 SPA
@@ -151,7 +151,7 @@ CUBEJS_JWT_CLAIMS_NAMESPACE=<CLAIMS_NAMESPACE>
 
 ## Testing with the Developer Playground
 
-### <--{"id" : "Testing with the Developer Playground"}-->  Retrieving a JWT
+### Retrieving a JWT
 
 Go to the [OpenID Playground from Auth0][link-openid-playground] to and click
 Configuration.
@@ -209,7 +209,7 @@ Copy the `access_token` from the response, and use the [JWT.IO
 Debugger][link-jwt-io-debug] to decode the token and verify any custom claims
 were successfully added.
 
-### <--{"id" : "Testing with the Developer Playground"}-->  Set JWT in Developer Playground
+### Set JWT in Developer Playground
 
 Now open the Developer Playground (at `http://localhost:4000`) and on the Build
 page, click Add Security Context.

docs/content/Auth/Overview.md

@@ -136,7 +136,7 @@ Cube.js has out-of-the-box support for the following identity providers:
 [ref-jwt-auth0]: /security/jwt/auth0
 [ref-jwt-aws-cognito]: /security/jwt/aws-cognito
 
-### <--{"id" : "Using JSON Web Key Sets (JWKS)"}-->  Configuration
+### Configuration
 
 As mentioned previously, Cube.js supports verifying JWTs using industry-standard
 JWKS. The JWKS can be provided either from a URL, or as a JSON object conforming
@@ -184,7 +184,7 @@ Or configure the same using environment variables:
 CUBEJS_JWK_URL='<URL_TO_JWKS_JSON>'
 ```
 
-### <--{"id" : "Using JSON Web Key Sets (JWKS)"}-->  Verifying claims
+### Verifying claims
 
 Cube.js can also verify the audience, subject and issuer claims in JWTs.
 Similarly to JWK configuration, these can also be configured in the `cube.js`
@@ -208,7 +208,7 @@ CUBEJS_JWT_ISSUER='<ISSUER_FROM_IDENTITY_PROVIDER>'
 CUBEJS_JWT_SUBJECT='<SUBJECT_FROM_IDENTITY_PROVIDER>'
 ```
 
-### <--{"id" : "Using JSON Web Key Sets (JWKS)"}-->  Custom claims namespace
+### Custom claims namespace
 
 Cube.js can also extract claims defined in custom namespaces. Simply specify the
 namespace in your `cube.js` configuration file:
@@ -221,10 +221,10 @@ module.exports = {
 };
 ```
 
-### <--{"id" : "Using JSON Web Key Sets (JWKS)"}-->  Caching
+### Caching
 
 Cube.js caches JWKS by default when [`CUBEJS_JWK_URL` or `jwt.jwkUrl` is
-specified](#configuration).
+specified](##using-json-web-key-sets-jwks-configuration).
 
 - If the response contains a `Cache-Control` header, then Cube.js uses it to
   determine cache expiry.
@@ -269,7 +269,7 @@ module.exports = {
   https://github.com/auth0/node-jsonwebtoken#token-expiration-exp-claim
 [link-jwt-libs]: https://jwt.io/#libraries-io
 [link-jwk-ref]: https://tools.ietf.org/html/rfc7517#section-4
-[ref-config-check-auth]: /config#check-auth
+[ref-config-check-auth]: /config#options-reference-check-auth
 [ref-config-migrate-cubejs]:
   /configuration/overview#migration-from-express-to-docker-template
 [ref-sec-ctx]: /security/context

docs/content/Auth/Security-Context.md

@@ -168,7 +168,7 @@ cube(`Orders`, {
 });
 ```
 
-### <--{"id" : "Using COMPILE_CONTEXT"}-->  Usage with Pre-Aggregations
+### Usage with Pre-Aggregations
 
 To generate pre-aggregations that rely on `SECURITY_CONTEXT` and/or
 `COMPILE_CONTEXT`, [configure `scheduledRefreshContexts` in your `cube.js`
@@ -184,12 +184,12 @@ build one from a JSON object.
 [link-auth0-jwks]:
   https://auth0.com/docs/tokens/json-web-tokens/json-web-key-sets
 [link-multitenancy]: /multitenancy-setup
-[ref-config-queryrewrite]: /config#query-rewrite
-[ref-config-sched-refresh]: /config#scheduled-refresh-contexts
-[ref-config-sec-ctx]: /config#security-context
-[ref-schema-sec-ctx]: /schema/reference/cube#security-context
+[ref-config-queryrewrite]: /config#options-reference-query-rewrite
+[ref-config-sched-refresh]: /config#options-reference-scheduled-refresh-contexts
+[ref-config-sec-ctx]: /config#request-context-security-context
+[ref-schema-sec-ctx]: /schema/reference/cube#context-variables-security-context
 [ref-cubes-compile-ctx]:
-  https://cube.dev/docs/cube#compile-context
+  https://cube.dev/docs/cube#context-variables-compile-context
 [ref-sec-ctx-vs-compile-ctx]:
   /multitenancy-setup#security-context-vs-multitenant-compile-context
 [ref-devtools-playground]:

docs/content/Caching/Getting-Started-Pre-Aggregations.md

@@ -181,7 +181,7 @@ it receives via the API. The process for selection is summarized below:
 
 You can find a complete flowchart [here][self-select-pre-agg].
 
-### <--{"id" : "Ensuring pre-aggregations are targeted by queries"}-->  Additivity
+### Additivity
 
 So far, we've described pre-aggregations as aggregated versions of your existing
 data. However, there are some rules that apply when Cube.js uses the
@@ -277,7 +277,7 @@ additive** query. Additive leaf measures can only be of the following
 
 [ref-schema-types-measure]: /types-and-formats#measures-types
 
-### <--{"id" : "Ensuring pre-aggregations are targeted by queries"}-->  Non-Additivity
+### Non-Additivity
 
 Using the same sample data for `line_items`, there's a `profit_margin` field
 which is different for each row. However, despite the value being numerical, it
@@ -421,7 +421,7 @@ cube(`LineItems`, {
 });
 ```
 
-### <--{"id" : "Ensuring pre-aggregations are targeted by queries"}-->  Selecting the pre-aggregation
+### Selecting the pre-aggregation
 
 To recap what we've learnt so far:
 
@@ -492,10 +492,10 @@ Some extra considerations for pre-aggregation selection:
   /caching/using-pre-aggregations#pre-aggregations-storage
 [ref-schema-dims]: /schema/reference/dimensions
 [ref-schema-joins]: /schema/reference/joins
-[ref-schema-joins-hasmany]: /schema/reference/joins#relationship
+[ref-schema-joins-hasmany]: /schema/reference/joins#parameters-relationship
 [ref-schema-preaggs]: /schema/reference/pre-aggregations
 [ref-schema-preaggs-origsql]:
-  /schema/reference/pre-aggregations#type-originalsql
+  /schema/reference/pre-aggregations#parameters-type-originalsql
 [self-select-pre-agg]:
-  #selecting-the-pre-aggregation
+  #ensuring-pre-aggregations-are-targeted-by-queries-selecting-the-pre-aggregation
 [wiki-gcd]: https://en.wikipedia.org/wiki/Greatest_common_divisor

docs/content/Caching/Overview.md

@@ -81,7 +81,7 @@ query hasn't changed, the cached value will be returned. Otherwise, an SQL query
 will be executed against either the pre-aggregations storage or the source
 database to populate the cache with the results and return them.
 
-### <--{"id" : "In-memory Cache"}-->  Refresh Keys
+### Refresh Keys
 
 Cube.js takes great care to prevent unnecessary queries from hitting your
 database. The first stage caching system caches query results in Redis (or in
@@ -124,7 +124,7 @@ If background refresh is disabled, Cube.js will refresh the cache during query
 execution. Since this could lead to delays in responding to end-users, we
 recommend always enabling background refresh.
 
-### <--{"id" : "In-memory Cache"}-->  Default Refresh Keys
+### Default Refresh Keys
 
 The default values for `refreshKey` are
 
@@ -137,7 +137,7 @@ Schema. Often, a `MAX(updated_at_timestamp)` for OLTP data is a viable option,
 or examining a metadata table for whatever system is managing the data to see
 when it last ran.
 
-### <--{"id" : "In-memory Cache"}-->  Disabling the cache
+### Disabling the cache
 
 There's no straightforward way to disable caching in Cube.js. The reason is that
 Cube.js not only stores cached values but also uses the cache as a point of
@@ -190,11 +190,11 @@ versions.
 
 [link-cube-cloud]: https://cube.dev/cloud
 [link-redis]: https://redis.io
-[ref-config-preagg-schema]: /config#pre-aggregations-schema
+[ref-config-preagg-schema]: /config#options-reference-pre-aggregations-schema
 [ref-dev-playground]: /dev-tools/dev-playground
 [ref-development-mode]: /configuration/overview#development-mode
 [ref-production-checklist]: /deployment/production-checklist
 [ref-production-checklist-refresh]:
   /deployment/production-checklist#set-up-refresh-worker
-[ref-schema-ref-cube-refresh-key]: /schema/reference/cube#refresh-key
+[ref-schema-ref-cube-refresh-key]: /schema/reference/cube#parameters-refresh-key
 [ref-schema-ref-preaggs]: /schema/reference/pre-aggregations

docs/content/Caching/Running-in-Production.md

@@ -220,4 +220,4 @@ allows requests from the Cube.js deployment.
 [ref-caching-partitioning]: /caching/using-pre-aggregations#partitioning
 [ref-config-env]: /reference/environment-variables#cube-store
 [ref-config-env-cloud-storage]:
-  /reference/environment-variables#cloud-storage
+  /reference/environment-variables#cube-store-cloud-storage

docs/content/Caching/Using-Pre-Aggregations.md

@@ -110,7 +110,7 @@ scanned and processed, and possibly even reduced cost, depending on your
 database solution. Cube.js supports partitioning data using the `timeDimension`
 property in [a pre-aggregation definition][ref-schema-ref-preaggs].
 
-### <--{"id" : "Partitioning"}-->  Time partitioning
+### Time partitioning
 
 Time-based partitioning is especially helpful for incremental refreshes; when
 configured, Cube.js will only refresh partitions as necessary. Without
@@ -272,7 +272,7 @@ memory before writing them to Cube Store (or an external database).
 If the dataset is large (more than 100k rows), then Cube.js can face issues when
 the Node runtime runs out of memory.
 
-### <--{"id" : "Optimizing Pre-Aggregation Build Times"}-->  Batching
+### Batching
 
 Batching is a more performant strategy where Cube.js sends compressed CSVs for
 Cube Store to ingest.
@@ -292,7 +292,7 @@ The performance scales to the amount of memory available on the Cube.js
 instance. Batching is automatically enabled for any databases that can support
 it.
 
-### <--{"id" : "Optimizing Pre-Aggregation Build Times"}-->  Export bucket
+### Export bucket
 
 When dealing with larger pre-aggregations (more than 100k rows), performance can
 be significantly improved by using an export bucket. This allows the source
@@ -323,29 +323,29 @@ retention policies to clean up the data in the export bucket as Cube.js does not
 currently manage this. For most use-cases, 1 day is sufficient.
 
 [ref-caching-in-mem-default-refresh-key]:
-  /caching#default-refresh-keys
+  /caching#in-memory-cache-default-refresh-keys
 [ref-config-connect-db]: /connecting-to-the-database
-[ref-config-driverfactory]: /config#driver-factory
+[ref-config-driverfactory]: /config#options-reference-driver-factory
 [ref-config-env]: /reference/environment-variables#cube-store
 [ref-config-env-general]: /config#general
-[ref-config-extdbtype]: /config#external-db-type
-[ref-config-extdriverfactory]: /config#external-driver-factory
+[ref-config-extdbtype]: /config#options-reference-external-db-type
+[ref-config-extdriverfactory]: /config#options-reference-external-driver-factory
 [ref-connect-db-athena]: /config/databases/aws-athena
 [ref-connect-db-redshift]: /config/databases/aws-redshift
 [ref-connect-db-bigquery]: /config/databases/google-bigquery
 [ref-connect-db-mysql]: /config/databases/mysql
 [ref-connect-db-postgres]: /config/databases/postgres
 [ref-connect-db-snowflake]: /config/databases/snowflake
-[ref-schema-timedimension]: /types-and-formats#types-time
+[ref-schema-timedimension]: /types-and-formats#dimensions-types-time
 [ref-schema-ref-preaggs]: /schema/reference/pre-aggregations
 [ref-schema-ref-preaggs-refresh-key]:
-  /schema/reference/pre-aggregations#refresh-key
+  /schema/reference/pre-aggregations#parameters-refresh-key
 [ref-schema-ref-preaggs-refresh-key-every]:
-  /schema/reference/pre-aggregations#refresh-key-every
+  /schema/reference/pre-aggregations#parameters-refresh-key-every
 [ref-schema-ref-preaggs-refresh-key-sql]:
-  /schema/reference/pre-aggregations#refresh-key-sql
+  /schema/reference/pre-aggregations#parameters-refresh-key-sql
 [ref-deploy-refresh-wrkr]: /deployment/overview#refresh-worker
 [ref-schema-ref-preaggs-sched-refresh]:
-  /schema/reference/pre-aggregations#scheduled-refresh
+  /schema/reference/pre-aggregations#parameters-scheduled-refresh
 [ref-prod-list-refresh]: /deployment/production-checklist#set-up-refresh-worker
 [wiki-partitioning]: https://en.wikipedia.org/wiki/Partition_(database)