Cross-Framework Libraries with Native Experiences Using React

Thank you for joining me today. I'm going to talk about how we are building cross-framework libraries using purely React and providing a superior experience for developers across different frameworks. At Sisense, we are building business intelligence applications, and we're highly focused on embedding analytics everywhere it is possible, and developers are no exception.

Our Composer's Decay, which we build, is to address the developer market that everybody has their own preference of building their own apps with their favourite frameworks. The challenge is how do we reach more developers? It's basically very simple. Developers have high standards for third-party libraries. They want it to be simple. They want to not go every second to the commentations. They want it to be understandable and follow the best practices of their own framework. And, to reach those developers, we need to meet those expectations.

To put it simply, the requirement is to reach those developers across frameworks, and utilise our organisation work force and future work force, which is React, which is still going strong in the work market. What is a native experience? In React, we know the JSX clearly, but in Vue.js, we have this templating syntax, and, in Angular, something similar, right? That's basically on the HTML part. In the business experience, React uses hooks, Vue uses something similar, but they call it composables, but in Angular, you have something called services. Clearly, they have differences in their business logic implementation, but we need to provide the same experience across all of those frameworks, while still developing only in React.

Our implementation strategies, we've first started, when I joined this effort, we had the POC with web components first, so we build the web components using a lead element, and we tried Stencil, and then we figured out that we need the bridge to create the native experience to make sure it is robust and scalable. In order to reach those frameworks, and web components is not that strong in the work force environment, and our organisation is not that proficient in web components development, and we found out that web components had some limitation at the time of research. Clearly, it was an option, but it was not as robust as we hoped it would be. But since we require a bridge anyway, so why not go with React, why we can't just build everything in React and then do some magic bridge, hopefully with one line of code, if possible? So, the strategy that I come up with is we're going to build everything with React, we will have a clear guidelines of how we do it, and then we bridge this with littlest effort to make it work with best experience across frameworks.

So of course, the choice for React was that there is a vast community, I think you know all the selling points, and we want to reuse also that we already have components in our organisation that has been using React, and we have the work force, and the market is strong like I said. So what is it about the React approach? We write all our components, all our UI in React. And the vision that I have seen is that if I can just call one function to render the React components internally hidden from the developers while still providing them the superior experience that they used to in their own framework, this could work. And what I know about React, we have an entry point where all we need is an element to mount React on, the component, the props, and optionally the context, and that is all that is required to render a React application. I use that as a basis to implement a solution. So in the bridge layer, what we're doing in the bridge layer, here's an example from Angular. So basically, we have created a very simple version of that mounting point called the component adapter where we pass the React component, we pass the context from the Angular site through their native solution which is the services, and we have a function that knows how to pass the arguments to a create element function with the React component that we desire to render, and then we will only apply this like whenever there is a life-cycle hook for changes, we just recall that function. Basically, we are re-rendering the React component inside Angular, and this is completely hidden from the developers. This is internal implementation. The end result that they get is on the right side, as you see, it's a basic Angular component, regular syntax, and of course, on the business side, they just do the regular Angular stuff. So in order for the business logic to work, we have to make sure we have a complete abstraction. For example, we do implement hooks in React, but the underlying business logic that is inside the hook is not framework agnostic. So basically, we can call those functions inside Angular and just wrap it and get the services or in the view composables. Basically, we serve everyone the way they want to. An example of implementing the execute query service is basically we call the execute query function, which is not framework agnostic, and we just get the same experience. What's important here is TypeScript. TypeScript is basically the secret ingredient to make this work because our commitment to the APIs, to the developer side is the same commitment across frameworks. Just because it's served a different way doesn't mean we have to change the APIs.

On the finishing notes, what's really important is to completely reuse what you are building inside your organization. Once you reuse it in other projects, you basically your own developer that is giving you yourself feedback, and always maintain that library, and you have to give the same commitment internally and externally, and then this library is working very well. That's it on my side. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.