diff --git a/docs/sdk/client-side/android/index.md b/docs/sdk/client-side/android/index.md index 25594568..5179547f 100644 --- a/docs/sdk/client-side/android/index.md +++ b/docs/sdk/client-side/android/index.md @@ -1,6 +1,7 @@ --- -title: Android reference +title: Android slug: /sdk/client-side/android +toc_max_heading_level: 4 --- import Tabs from '@theme/Tabs'; @@ -8,6 +9,12 @@ import TabItem from '@theme/TabItem'; This category contains topics explaining how to configure Bucketeer's Android SDK. +:::tip Android SDK Version (Stable) + +Bucketeer Android SDK has reached the production stage, offering you a stable and reliable experience. + +::: + :::info Compatibility The Bucketeer SDK is compatible with Android SDK versions 21 and higher (Android 5.0, Lollipop). @@ -52,9 +59,11 @@ import io.bucketeer.sdk.android.* Configure the SDK config and user configuration. -:::note +:::info + +The **featureTag** setting is the tag you configure when creating a Feature Flag. It will evaluate all the Feature Flags in the environment when it is not configured. -The **featureTag** setting is the tag you configure when creating a Feature Flag. +**We strongly recommend** using tags to speed up the evaluation process and reduce the cache size in the client. ::: @@ -110,20 +119,19 @@ val client = BKTClient.getInstance() -:::note +:::info Default timeout -The initialize process immediately starts polling the latest evaluations from Bucketeer in the background using the interval `pollingInterval` configuration while the application is in the **foreground state**. -When the application changes to the **background state**, it will use the `backgroundPollingInterval` configuration. +The initialize process default timeout is 5 seconds. -::: +Once initialization is finished, all the requests in the SDK use a timeout of 30 seconds. -If you want to use the feature flag on Splash or Main views, and the user opens your application for the first time, it may not have enough time to fetch the variations from the Bucketeer server. +::: -For this case, we recommend using the `Future` returned from the initialize method. +If you want to use the feature flag on Splash or Main views, the SDK cache may be old or not exist and may not have enough time to fetch the variations from the Bucketeer server. In this case, we recommend using the `Future` returned from the initialize method. In addition, you can define a custom timeout. -:::note +:::caution Initialization Timeout error -Be aware that if an error is returned in the initialize process, it is regarding the fetch evaluation timeout error, not the initialize process itself. +During the initialization process, errors **are not** related to the initialization itself. Instead, they arise from a timeout request, indicating the variations data from the server weren't received. Therefore, the SDK will work as usual and update the variations in the next [polling](android#polling) request. ::: @@ -158,6 +166,96 @@ viewLifecycleOwner.lifecycleScope.launch { +#### Polling + +The initialize process immediately starts polling the latest evaluations from the Bucketeer server in the background using the interval `pollingInterval` configuration while the application is in the **foreground state**. +When the application changes to the **background state**, it will use the `backgroundPollingInterval` configuration. + +#### Polling retry behavior + +The Bucketeer SDK regularly polls the latest evaluations from the server based on the pollingInterval parameter. By default, the `pollingInterval` is set to 10 minutes, but you can adjust it to suit your needs. + +If a polling request fails, the SDK initiates a retry procedure. The SDK attempts a new polling request every minute up to 5 times. If all five retry attempts fail, the SDK sends a new polling request once the `pollingInterval` time elapses. The table below shows this scenario: + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Polling TimeRetry TimeRequest Status
10:00-Fail
- 10:01Fail
- 10:02Fail
- 10:03Fail
-10:04Fail
-10:05Fail
10:10-Successful
+
+ +The polling counter, which uses the `pollingInterval` information, resets in case of a successful retry. The table below shows the described scenario. +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Polling TimeRetry TimeRequest status
10:00-Fail
- 10:01Successful
10:11-Successful
+
+ ## Supported features ### Evaluating user diff --git a/docs/sdk/client-side/flutter/index.md b/docs/sdk/client-side/flutter/index.md index 6adc55c5..bd0c4c8d 100644 --- a/docs/sdk/client-side/flutter/index.md +++ b/docs/sdk/client-side/flutter/index.md @@ -1,6 +1,7 @@ --- -title: Flutter reference +title: Flutter slug: /sdk/client-side/flutter +toc_max_heading_level: 4 --- import Tabs from '@theme/Tabs'; @@ -8,6 +9,14 @@ import TabItem from '@theme/TabItem'; This category contains topics explaining how to configure Bucketeer's Flutter SDK. +:::caution Flutter SDK Version (Beta) + +The Flutter JS SDK is currently in its Beta stage. + +If you find any issues or have suggestions for improvement, feel free to open an [issue](https://github.com/bucketeer-io/flutter-client-sdk/issues). + +::: + ## Getting started Before starting, ensure that you follow the [Getting Started](/getting-started) guide. @@ -45,9 +54,11 @@ import 'package:bucketeer_flutter_client_sdk/bucketeer_flutter_client_sdk.dart'; Configure the SDK config and user configuration. -:::note +:::info -The **featureTag** setting is the tag you configure when creating a Feature Flag. +The **featureTag** setting is the tag you configure when creating a Feature Flag. It will evaluate all the Feature Flags in the environment when it is not configured. + +**We strongly recommend** using tags to speed up the evaluation process and reduce the cache size in the client. ::: @@ -105,30 +116,136 @@ final client = BKTClient.instance; -:::note +:::info Default timeout + +The initialize process default timeout is 5 seconds. -The initialize process immediately starts polling the latest evaluations from Bucketeer in the background using the interval `pollingInterval` configuration while the application is in the **foreground state**. When the application changes to the **background state**, it will use the `backgroundPollingInterval` configuration. +Once initialization is finished, all the requests in the SDK use a timeout of 30 seconds. ::: -If you want to use the feature flag on Splash or Main views, and the user opens your application for the first time, it may not have enough time to fetch the variations from the Bucketeer server. +If you want to use the feature flag on Splash or Main views, the SDK cache may be old or not exist and may not have enough time to fetch the variations from the Bucketeer server. In this case, we recommend using `await` in the initialize method. In addition, you can define a custom timeout. -For this case, we recommend using the `timeout` option in the initialize method. It will block until the SDK receives the latest user variations. +:::caution Initialization Timeout error + +During the initialization process, errors **are not** related to the initialization itself. Instead, they arise from a timeout request, indicating the variations data from the server weren't received. Therefore, the SDK will work as usual and update the variations in the next [polling](flutter#polling) request. + +::: ```dart showLineNumbers /// It will unlock without waiting until the fetching variation process finishes -int timeout = 1000; +int timeout = 5000; -await BKTClient.initialize(config: config, user: user, timeoutMillis: timeout); -final client = BKTClient.instance; +final result = await BKTClient.initialize(config: config, user: user, timeoutMillis: timeout); + +if (result.isSuccess) { + final client = BKTClient.instance; + if (showNewFeature) { + /// The Application code to show the new feature + } else { + /// The code to run if the feature is off + } +} else { + /// Handle the error when there is no cache or the cache is not updated +} ``` +#### Polling + +The initialize process immediately starts polling the latest evaluations from the Bucketeer server in the background using the interval `pollingInterval` configuration while the application is in the **foreground state**. +When the application changes to the **background state**, it will use the `backgroundPollingInterval` configuration. + +#### Polling retry behavior + +The Bucketeer SDK regularly polls the latest evaluations from the server based on the pollingInterval parameter. By default, the `pollingInterval` is set to 10 minutes, but you can adjust it to suit your needs. + +If a polling request fails, the SDK initiates a retry procedure. The SDK attempts a new polling request every minute up to 5 times. If all five retry attempts fail, the SDK sends a new polling request once the `pollingInterval` time elapses. The table below shows this scenario: + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Polling TimeRetry TimeRequest Status
10:00-Fail
- 10:01Fail
- 10:02Fail
- 10:03Fail
-10:04Fail
-10:05Fail
10:10-Successful
+
+ +The polling counter, which uses the `pollingInterval` information, resets in case of a successful retry. The table below shows the described scenario. +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Polling TimeRetry TimeRequest status
10:00-Fail
- 10:01Successful
10:11-Successful
+
+ ## Supported features ### Evaluating user @@ -203,7 +320,7 @@ if (result.isSuccess) { /// The code to run if the feature is off } } else { - /// The code to run if the feature is off + /// Handle the error when there is no cache or the cache is not updated } ``` diff --git a/docs/sdk/client-side/ios/index.md b/docs/sdk/client-side/ios/index.md index e558766d..f2150581 100644 --- a/docs/sdk/client-side/ios/index.md +++ b/docs/sdk/client-side/ios/index.md @@ -1,6 +1,7 @@ --- -title: iOS reference +title: iOS slug: /sdk/client-side/ios +toc_max_heading_level: 4 --- import Tabs from '@theme/Tabs'; @@ -8,6 +9,12 @@ import TabItem from '@theme/TabItem'; This category contains topics explaining how to configure Bucketeer's iOS SDK. +:::tip iOS SDK Version (Stable) + +Bucketeer iOS SDK has reached the production stage, offering you a stable and reliable experience. + +::: + :::info Compatibility The Bucketeer iOS SDK is compatible with iOS versions 11.0 and higher. @@ -87,9 +94,11 @@ import Bucketeer Configure the SDK config and user configuration. -:::note +:::info -The **featureTag** setting is the tag you configure when creating a Feature Flag. +The **featureTag** setting is the tag you configure when creating a Feature Flag. It will evaluate all the Feature Flags in the environment when it is not configured. + +**We strongly recommend** using tags to speed up the evaluation process and reduce the cache size in the client. ::: @@ -148,22 +157,23 @@ BKTClient.initialize(config: config, user: user) -:::note +:::info Default timeout -The initialize process immediately starts polling the latest evaluations from Bucketeer in the background using the interval `pollingInterval` configuration while the application is in the **foreground state**. When the application changes to the **background state**, it will use the `backgroundPollingInterval` configuration when the [Background fetch](/sdk/client-side/ios#background-fetch) is configured. +The initialize process default timeout is 5 seconds. -::: +Once initialization is finished, all the requests in the SDK use a timeout of 30 seconds. -If you want to use the feature flag on Splash or Main views, and the user opens your application for the first time, it may not have enough time to fetch the variations from the Bucketeer server. +::: -For this case, we recommend using the callback in the initialize method. +If you want to use the feature flag on Splash or Main views, the SDK cache may be old or not exist and may not have enough time to fetch the variations from the Bucketeer server. In this case, we recommend using the callback in the initialize method. In addition, you can define a custom timeout. -:::note +:::caution Initialization Timeout error -Be aware that if an error is returned in the initialize process, it is regarding the fetch evaluation timeout error, not the initialize process itself. +During the initialization process, errors **are not** related to the initialization itself. Instead, they arise from a timeout request, indicating the variations data from the server weren't received. Therefore, the SDK will work as usual and update the variations in the next [polling](ios#polling) request. ::: + @@ -176,15 +186,15 @@ BKTClient.initialize( timeoutMillis: timeout ) { error in guard error == nil else { - // The code to run when there is an error while initializing the SDK + // Handle the error when there is no cache or the cache is not updated return } let client = BKTClient.shared let showNewFeature = client.boolVariation(featureId: "YOUR_FEATURE_FLAG_ID", defaultValue: false) if (showNewFeature) { - // The Application code to show the new feature + // The Application code to show the new feature } else { - // Handle the error when there is no cache or the cache is not updated + // The code to run when the feature is off } } ``` @@ -192,6 +202,98 @@ BKTClient.initialize( + +#### Polling + +The initialize process immediately starts polling the latest evaluations from the Bucketeer server in the background using the interval `pollingInterval` configuration while the application is in the **foreground state**. When the application changes to the **background state**, it will use the `backgroundPollingInterval` configuration when the [Background fetch](/sdk/client-side/ios#background-fetch) is configured. + +#### Polling retry behavior + +The Bucketeer SDK regularly polls the latest evaluations from the server based on the pollingInterval parameter. By default, the `pollingInterval` is set to 10 minutes, but you can adjust it to suit your needs. + +If a polling request fails, the SDK initiates a retry procedure. The SDK attempts a new polling request every minute up to 5 times. If all five retry attempts fail, the SDK sends a new polling request once the `pollingInterval` time elapses. The table below shows this scenario: + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Polling TimeRetry TimeRequest Status
10:00-Fail
- 10:01Fail
- 10:02Fail
- 10:03Fail
-10:04Fail
-10:05Fail
10:10-Successful
+
+ +The polling counter, which uses the `pollingInterval` information, resets in case of a successful retry. The table below shows the described scenario. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Polling TimeRetry TimeRequest status
10:00-Fail
- 10:01Successful
10:11-Successful
+
+ + ## Supported features ### Evaluating user diff --git a/docs/sdk/client-side/javascript/index.md b/docs/sdk/client-side/javascript/index.md index f684efa6..2539baf7 100644 --- a/docs/sdk/client-side/javascript/index.md +++ b/docs/sdk/client-side/javascript/index.md @@ -1,6 +1,7 @@ --- -title: JavaScript reference +title: JavaScript slug: /sdk/client-side/javascript +toc_max_heading_level: 4 --- import Tabs from '@theme/Tabs'; @@ -8,6 +9,12 @@ import TabItem from '@theme/TabItem'; This category contains topics explaining how to configure Bucketeer's JavaScript SDK. +:::tip JavaScript SDK Version (Stable) + +Bucketeer JavaScript SDK has reached the production stage, offering you a stable and reliable experience. + +::: + ## Getting started Before starting, ensure that you follow the [Getting Started](/getting-started) guide. @@ -53,11 +60,14 @@ Configure the SDK config and user configuration. :::info -The **featureTag** setting is the tag you configure when creating a Feature Flag. It will evaluate all the Feature Flags in the environment when it is not configured.
+The **featureTag** setting is the tag you configure when creating a Feature Flag. It will evaluate all the Feature Flags in the environment when it is not configured. + **We strongly recommend** using tags to speed up the evaluation process and reduce the cache size in the client. ::: +All the settings in the example below are required. + @@ -84,7 +94,7 @@ Depending on your use, you may want to change the optional configurations availa - **pollingInterval** (Minimum 5 minutes. Default is 10 minutes) - **eventsFlushInterval** (Default is 30 seconds) - **eventsMaxQueueSize** (Default is 50 events) -- **storageKeyPrefix** (Default is empty) +- **storageKeyPrefix** (Default is empty) - **userAgent** (Default is `window.navigator.userAgent`) - **fetch** (Default is `window.fetch`) @@ -111,15 +121,21 @@ const client = getBKTClient(); -:::note +:::info Default timeout + +The initialize process default timeout is 5 seconds. -The initialize process starts polling right away the latest evaluations from Bucketeer in the background using the interval `pollingInterval` configuration. JavaScript SDK **does not support** Background fetch. +Once initialization is finished, all the requests in the SDK use a timeout of 30 seconds. ::: -If you want to use the feature flag on Splash or Main views, and the user opens your application for the first time, it may not have enough time to fetch the variations from the Bucketeer server. +If you want to use the feature flag on Splash or Main views, the SDK cache may be old or not exist and may not have enough time to fetch the variations from the Bucketeer server. In this case, we recommend using the `Promise` returned from the initialize method. The Promise rejects with `BKTException` when something goes wrong. + +:::caution Initialization Timeout error -For this case, we recommend using the `Promise` returned from the initialize method. The Promise rejects with `BKTException` when something goes wrong. +During the initialization process, errors **are not** related to the initialization itself. Instead, they arise from a timeout request, indicating the variations data from the server weren't received. Therefore, the SDK will work as usual and update the variations in the next [polling](javascript#polling) request. + +::: @@ -138,13 +154,103 @@ initialFetchPromise } }) .catch((error) => { - // Handle the error + // Handle the error when there is no cache or the cache is not updated }); ``` +#### Polling + +The initialize process starts polling right away the latest evaluations from the Bucketeer server in the background using the interval `pollingInterval` configuration. JavaScript SDK **does not support** Background fetch. + +#### Polling retry behavior + +The Bucketeer SDK regularly polls the latest evaluations from the server based on the pollingInterval parameter. By default, the `pollingInterval` is set to 10 minutes, but you can adjust it to suit your needs. + +If a polling request fails, the SDK initiates a retry procedure. The SDK attempts a new polling request every minute up to 5 times. If all five retry attempts fail, the SDK sends a new polling request once the `pollingInterval` time elapses. The table below shows this scenario: + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Polling TimeRetry TimeRequest Status
10:00-Fail
- 10:01Fail
- 10:02Fail
- 10:03Fail
-10:04Fail
-10:05Fail
10:10-Successful
+
+ +The polling counter, which uses the `pollingInterval` information, resets in case of a successful retry. The table below shows the described scenario. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Polling TimeRetry TimeRequest status
10:00-Fail
- 10:01Successful
10:11-Successful
+
+ ### Handling exceptions While most of the time error is handled internally, some methods throw `BKTException` when something goes wrong. diff --git a/docs/sdk/index.md b/docs/sdk/index.md deleted file mode 100644 index c32c3416..00000000 --- a/docs/sdk/index.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -id: overview -title: SDK Overview -slug: /sdk ---- - -In this category, you will find guides explaining the difference between **client** and **server-side** SDKs. To connect to the Bucketeer server, you will need an SDK for your programming language and an API key. - -:::note - -The API Key is generated on the Bucketeer dashboard from the **API Keys** menu. - -::: - -## Choose a Bucketeer SDK - -When integrating a Bucketeer SDK with your code, it is important to consider two factors. - -1. First, you need to assess your specific requirements to determine whether you need a server-side or client-side SDK. Typically, you will only need one SDK per application or service. However, you can use multiple SDKs if your product consists of applications or services written in multiple languages. -2. Afterward, you need to select the programming language which will normally be used on your system. - -:::tip - -We strongly recommend that you check our [Quickstart](/getting-started/quickstart) guide before using Bucketeer SDKs in your application. - -::: - -### Client-side SDK - -Client-side SDKs are designed for single-user desktop, mobile, and embedded applications. They are intended for use in potentially less secure environments, such as personal computers or mobile devices, including mobile SDKs. These SDKs typically run on end-user devices, which makes them vulnerable to compromise by users who unpack a mobile app to examine the SDK bytecode or use developer tools in their browser to inspect internal site data. Therefore, never using a server-side SDK key in a client-side or mobile application is essential. - -Supported SDKs for client-side: - - -
- -
- - - Android - -
- -
- - - iOS - -
- -
- - - Flutter - -
- -
- - - JavaScript - -
- -
- -### Server-side SDK - -Server-side SDKs are designed for multi-user systems and intended for use in trusted environments, like corporate networks or web servers. They operate within server-architected applications running on your infrastructure or trusted cloud-based infrastructure. These locations are not directly accessible by end-users. The restricted access of server-based applications allows server-side SDKs to safely receive flag data and rulesets without the need to filter out sensitive information. This setup enables server-side SDKs to receive flag data including rules, and segments safely without filtering out sensitive information. - -Supported SDKs for server-side: - -
- -
- - - Go - -
- -
- - - Node.js - -
- -
diff --git a/docs/sdk/index.mdx b/docs/sdk/index.mdx new file mode 100644 index 00000000..c8c36342 --- /dev/null +++ b/docs/sdk/index.mdx @@ -0,0 +1,242 @@ +--- +id: overview +title: SDK Overview +slug: /sdk +--- + +import CheckSVG from '@site/src/components/checkSvg/CheckSVG'; +import UncheckSVG from '@site/src/components/uncheckSvg/UncheckSVG'; + + +In this category, you will find guides explaining the difference between **client** and **server-side** SDKs. To connect to the Bucketeer server, you will need an SDK for your programming language and an API key. + +:::note + +The API Key is generated on the Bucketeer dashboard from the **API Keys** menu. + +::: + +## Choose a Bucketeer SDK + +When integrating a Bucketeer SDK with your code, it is important to consider two factors. + +1. First, you need to assess your specific requirements to determine whether you need a server-side or client-side SDK. Typically, you will only need one SDK per application or service. However, you can use multiple SDKs if your product consists of applications or services written in multiple languages. +2. Afterward, you need to select the programming language which will normally be used on your system. + +:::tip + +We strongly recommend that you check our [Quickstart](/getting-started/quickstart) guide before using Bucketeer SDKs in your application. + +::: + +### Client-side SDK + +Client-side SDKs are designed for single-user desktop, mobile, and embedded applications. They are intended for use in potentially less secure environments, such as personal computers or mobile devices, including mobile SDKs. These SDKs typically run on end-user devices, which makes them vulnerable to compromise by users who unpack a mobile app to examine the SDK bytecode or use developer tools in their browser to inspect internal site data. Therefore, never using a server-side SDK key in a client-side or mobile application is essential. + +Supported SDKs for client-side: + + +
+ +
+ + + Android + +
+ +
+ + + iOS + +
+ +
+ + + Flutter + +
+ +
+ + + JavaScript + +
+ +
+ +#### Client available features + +The table below illustrates all features available in each one of the available Client SDKs. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeatureAndroid iOSFlutterJavascript
Evaluating user
Variation types
Updating user evaluations
Updating user evaluations in real-time
Reporting custom events
Flushing events
User attributes configuration
Updating user attributes
Getting user information
Getting evaluation details
Listening to evaluation updates
Background mode
+
+ + + +### Server-side SDK + +Server-side SDKs are designed for multi-user systems and intended for use in trusted environments, like corporate networks or web servers. They operate within server-architected applications running on your infrastructure or trusted cloud-based infrastructure. These locations are not directly accessible by end-users. The restricted access of server-based applications allows server-side SDKs to safely receive flag data and rulesets without the need to filter out sensitive information. This setup enables server-side SDKs to receive flag data including rules, and segments safely without filtering out sensitive information. + +Supported SDKs for server-side: + +
+ +
+ + + Go + +
+ +
+ + + Node.js + +
+ +
+ +#### Server available features + +The table below illustrates all features available in each one of the available Server SDKs. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeatureGoNode Js
Evaluating user
Variation types
Reporting custom events
Flushing events
User attributes configuration
+
\ No newline at end of file diff --git a/docs/sdk/server-side/go/index.md b/docs/sdk/server-side/go/index.md index d70be5d3..60cddbfa 100644 --- a/docs/sdk/server-side/go/index.md +++ b/docs/sdk/server-side/go/index.md @@ -1,5 +1,5 @@ --- -title: Go reference +title: Go sidebar_position: 1 slug: /sdk/server-side/go --- diff --git a/docs/sdk/server-side/node-js/index.md b/docs/sdk/server-side/node-js/index.md index 462a1d47..99172137 100644 --- a/docs/sdk/server-side/node-js/index.md +++ b/docs/sdk/server-side/node-js/index.md @@ -1,5 +1,5 @@ --- -title: Node JS reference +title: Node JS sidebar_position: 1 slug: /sdk/server-side/node-js --- diff --git a/src/components/checkSvg/CheckSVG.jsx b/src/components/checkSvg/CheckSVG.jsx new file mode 100644 index 00000000..1d780474 --- /dev/null +++ b/src/components/checkSvg/CheckSVG.jsx @@ -0,0 +1,12 @@ +import React from 'react'; +import useBaseUrl from '@docusaurus/useBaseUrl'; + +export default function CheckSVG() { + return ( + + + + + ); +} diff --git a/src/components/uncheckSvg/UncheckSVG.jsx b/src/components/uncheckSvg/UncheckSVG.jsx new file mode 100644 index 00000000..4604064b --- /dev/null +++ b/src/components/uncheckSvg/UncheckSVG.jsx @@ -0,0 +1,12 @@ +import React from 'react'; +import useBaseUrl from '@docusaurus/useBaseUrl'; + +export default function UncheckSVG() { + return ( + + + + + ); +} diff --git a/src/css/custom.css b/src/css/custom.css index 64bcbb02..4279ca15 100644 --- a/src/css/custom.css +++ b/src/css/custom.css @@ -941,6 +941,28 @@ code { } /*-------------------------------- Tables configuration ------------------------------ */ +.center-table { + display: flex; + justify-content: center; +} + +.sdk-table table { + box-sizing: border-box; + width: 100% !important; + table-layout: fixed; +} + +.sdk-table table th { + min-width: 100px; + width: 100%; + table-layout: auto; +} + +@media screen and (max-width: 1050px) { + .sdk-table table th { + min-width: 0; + } +} table thead th { background-color: #ddd7e9;