Web library integration

Last updated on August 26th, 2022 – Web Library version 0.7.0

The Web Library is available to all our Build subscribers. Its integration is optional but will allow increased stability and performance. Coming soon, some key features will be available for our Clients using the Web Library!

Load the script

Integrate in the website header the loading of the script.

Script versions

Depending of the moment when the website wants to call the JS functions, we recommend using the defer attribute for the script. Using this rule, we are sure that the script is loaded before the DOMContentLoaded event.

Version 0.7.0

<head>
<script defer src="https://builder-sdks.bryj.ai/websdk/0.7.0/BuildWebSDK.min.js"></script>
</head>

Release notes :

  • remove UserAgent dependency

Public API

The script exposes 2 Public APIs to interact with the native BuildSDK. Those APIs are independent, they do not interact which each other.

Set the current loginState of a User

You can find below an example of call for each logged in state you can set through the web library:

  • If the user is logged in
window.bridgeWebSDK.setCurrentLoginState(window.bridgeWebSDK.loginStates.isLoggedIn);
  • If the user is logged out
window.bridgeWebSDK.setCurrentLoginState(window.bridgeWebSDK.loginStates.isNotLoggedIn);
  • If the user encountered a login error (wrong email, wrong password or any error which may exist on the website)
window.bridgeWebSDK.setCurrentLoginState(window.bridgeWebSDK.loginStates.loginError);
Those calls must be fired when:
– Any new content is loaded (page refresh…).
– The login state changes. More specifically after a redirect after logging in or out, the website should not wait for a refresh of the page to send the login state.
The above will ensure optimal behavior of the mobile apps
Technically, here some examples to notify the SDK (but can it depends on the each Website)
– During the page loading :
– on document DOMContentLoaded event, if the website is able to know the user login state,
– on document complete, if the website has the login state information.

– Dynamically:
– If the User Session expired,
– If the User Login State changed (login and logout process),
– If the login state changes. More specifically after a redirect after logging in or out, the website should not wait for a refresh of the page to send the login state.

The above will ensure optimal behavior of the mobile apps

Set cart value

window.bridgeWebSDK.setCartValue(10);
This call must be fired when:
– Any new content is loaded (page refresh…).
– The cart badge value changes. More specifically after adding or removing one or several items from the cart. The website should not wait for a refresh of the page to send the latest cart value.
The above will ensure optimal behavior of the mobile apps

Why adopt/implement those methods on the website

Stability

The login state is sometimes complicated to evaluate. The native BuildSDK uses complex logic via DOM inspection, cookies scanning, local storage. This logic is not always 100% stable as website changes can break it.

Performance

The active scanning for the login state on the website is executed very often (10x per seconds). If the website take this responsibility we are able to remove the active scanning and change the BuildSDK to a passive mode.

Responsibilities

Login state active → passive

When the native BuildSDK receives one message about the login state, the buildSDK will stop evaluating the login state itself.

The role of the Login state mechanism

The login State is THE MOST critical value of the SDK. This value impacts :

  • the autoLogin process (on the App Start, when the SDK try to autoLogin you)
  • the refresh session process (on background → foreground , when the SDK check the session and try to autoLogin you)
  • saving Credentials (when the User enter his Credentials, if the login state becomes isLoggedIn, the SDK will save the Credentials to a secure space)

Cart number active → passive

When the native BuildSDK receives one message about the Cart Value, the buildSDK will stop evaluating the cart value itself.

Cart number is not just a number

The cart is an important number for the BuildSDK. The BuildSDK can load multiple WebViews at the same time, if the Cart number changes within one of the WebViews, that is an important event that indicates that other WebViews needs to be reloaded.