lynx-ui: Best Lynx in Components

All right, what's up React Advance London? So this is Shun, aka Hux Pro. It used to stand for professional, but I guess it's procrastination nowadays. So it's great to be here. It's actually my very first time in UK. So thanks to GitNation to invite us here.

So today, let's talk about components. So you may ask, wait, why are we talking about components in 2025? Isn't it already solved by React and Chessie and UI? I mean, sort of. Building production-grade components is still very hard. This is a quote from Chessie when people didn't realize it's pretty hard.

So definitely shout out to Chessie and Redix UI, the people behind it, because they made incredible work to make this happen. But I'm hesitant to say the component problem is completely solved because of mobile web. If you think about it, components, it only helps from one hand. It helps with the developer experience by encapsulating all the great user experiences into reusable and composable units. But there is another hand. On the other hand, what if the platform doesn't have a very high ceiling for user experience? That doesn't help.

So let's look at the real mobile application. You've got a livestream over there. You can scroll, there are some sticky headers, and then you can horizontal scroll that little things, and you can also do another horizontal scroll, and then auto-scroll to the top. It's just a bunch of very complicated scrolling. Can you imagine building this on mobile web? If this is too complicated for you to capture the idea, there's a simpler one. It's very simple. It's just two screens concurrently scroll to items. It's simple, yet it's impossible on mobile web.

These two screens are actually real products. TikTok. They're not built with mobile web. It's built with a technology called LYNX. I hope you already heard about it, since we're open source in March. But if you haven't heard about it, LYNX is basically like web. It's a cross-platform technology, which means you can write code once and render to many different platforms. iOS, Android, web, desktop. You can reuse your existing knowledge for web, like CSS variables and React use state. It renders to native views so that you can do all those fancy scrolling that we mentioned before.

Are we done? It feels like we already got the best of both worlds. Well, only until we zoom in and we take a closer look on the real complexity of building actual products. In that regard, we're still far from the velocity that you are, the product developers, the web developers want from the web. If all the components are native components, you ended up with something like the native select, like the selected tag on the web. On the other hand, we have something like ShedCN select. You can build everything with React, with JavaScript. You can iterate however you want.

So yeah, it's very native. You got iOS liquid glass in the first state, but it's almost never changed. You have zero customizability, right? On the other hand, we have something like ShedCN select. You can build everything with React, with JavaScript. You can iterate however you want. You can compose however you want. It's extremely customizable. It just doesn't give you the native UX that we want. So this dilemma made us start to do research again. Is it possible that we can try to be closer to the best of both worlds again, like one more time?

So today, we'll introduce you to the newest member of Lynx family of technologies. It's called Lynx UI. It is a set of ready-to-use components where we try to preserve the native great user experiences while delivering the velocity and developer experiences of web. To give you a walkthrough of some of the components, and also a deep dive into the design, the engineering details of this beautiful craft data components that, please welcome one of the creators to the stage, Fangzhou.

Hi, I'm Fangzhou. I'm one of the creators in Lynx UI. Today, I would like to show you what we have built in Lynx UI and how we built it. I know that a common engineering process for front-end engineers is like this. So you think about HTML first, and then comes to styles, and the last thing that comes to your mind is DGS. But as a component library builder, we handle the hardest thing first. That's the JS part. As a cross-platform infrastructure, the Lynx engine provides us with a set of high-performance native elements and these native elements are very great. Let's show you some of them. Let's start with the score view. For example, this score view, it provides us a seamless scoring experience that really stuck at 120fps. And the next one, the list. It's also some kind of score view, but it can also help us to handle the high-performance part that has the recycle and reuse abilities. And then we have this score coordinator. So what does it do? This score coordinator, as its name says, it coordinates two score containers that are in the same score direction. So, this behavior seems normal on the mobile, yet not an easy task to finish on web. Here's what we can do on the web.

The inner score container scores first, and then it leaves the header behind. Well, with score coordinator, the native helps you fix it. The header gives the priority. It collapses completely before the inner content begins to score, ensuring a smooth and intuitive experience. So, the mobile can even do something more programmable. Like this. So we can do a not-sync score behavior here. We can even circle on our fingers and the outside, the vertical score container will move a bit. And after some configuration, we can just make them move together. It's totally programmable and fully customizable. And when we add some dedicated score behavior, snapping behaviors to our score containers, it becomes the view pager. With all that well-built X elements, we have a solid native-graded UI primitives.

So, how do we build a highly customizable interaction in Lynx? A very direct solution to this is to add some JS to it. That's where the Lynx UI stands. We took these solid native elements and made them even better with JavaScript and also with the web eco. So, let's start with this swiper. This swiper is a perfect case study for deriving clean JS logic from the foundation of the native wheel. So swiper is a type of corosal that displays a collection of items. Users can navigate through them manually or allow them to cycle automatically. The manual swipe interaction in swiper we built is a fundamental logic that attach delta in, transform out. This means the component tracks the distance from the user finger moves, the delta, and directly translates that into a corresponding visual transformation of the content.

But before we go any forward, we have to recall that the Lynx actually has a draw-threaded model, thread model. So, we do have another thread in Lynx. We can call it the main thread and the background thread. If we handle those events as we usually do in the background thread, the JS thread, you will introduce cross-thread latency like this. But if we do them all together in that main thread, then your attachment will have an even better user experience. So, how to allow executing it synchronously? The bad news is we have to make some changes to our code. But the good news is the change is very easy. So first of all, we make that wheel ref as the main thread ref. Then we put this main thread mark on each of the events and the functions.

And there you go. You have already moved everything you need into the main thread. So, this is a very basic mode of Swiper. Now we have the MTS version of basic mode, then what about to introduce a mode called custom? How to build this custom mode? It's very easy. So, we just put another main thread customized animation props to the Swiper. And thanks to the powerful main thread scripts we have, whatever pass through that custom animation function will be caught in each frame during the interaction.

What we can do is it. What's even more powerful is we aren't just limited to this transform. We can apply all other principles to any properties like the rotation, the scale, the opacity. So let's add them all. Why not just put them all together into that main thread custom animation and see what happens. The Swiper you have here just becomes a Tinder card. It's not like anything in the basic mode, right? So, that's what we can build on top of Vue, the native Vue. We're using MTS.

But don't forget we have these even more powerful native elements. What about build some MTS logic on top of that native elements? Such as the fiddlist. Fiddlist is a combination of MTS and list. We build a proper pool to refresh ability on top of it. So, what happens in fiddlist is a very good case that shows how a seamless bridge between a pure native element and those powered by MTS. So let's see how we do it. So, first we listen to what this native element says. It's the main thread on scroll to upper edge. And we put a listener here. Only when it reaches to the edge will we hand this interactions to the MTS. But before that, we just do nothing. So, after we reach that edge, we can build another component. That's MTS plus Vue pager, that's dynamic Vue pager. What it can do is it can handle different... What if your Vue pager items have different heights? It can help you dynamically calculate the heights and do all the easing functions of its size.

Of its size. The first step is to get a rift of not Vue, but Vue pager. And then receive the message from it. The on offset change. And we simply do the calculation and changes the height of the Vue pager. And that's it. The Vue pager will change dynamically when you score it with your hand.

So, what if we build the MTS logic on top of multiple native elements? Let's see the tabs. The tabs is a combination of Vue pager and score view. The score view is responsible to the upper side of the tab bar and Vue pager is the lower side panel. And we build that cute little indicators with just a native Vue.

And these indicators can be adjusted by this set indicator left and set indicator with single ticks. And the score view here, it will be responsible to do the... To its own score behavior. Of course, your tab bar can score, right? And the indicator size and position are calculated by... Actually not by the score view, but by the Vue pager. The core challenge here is how to synchronize the tabs indicators behavior between this Vue pager and the score view. This requires implementing a smooth animation for the indicator and ensuring position updates.

Of course, we can still use MTS here. So that's you already know. So we actually... After building that, we have this structure of our new components. That says the reusable and high performance interactions with zero lagging because we have MTS. After this part, we have finished the interaction part from native to web. And let's start the next part. That's how to build our component in a more composable way. Let's see how the example of a single dialog. So if we build a dialog like this, the internal structure of a totally encapsulated component like it is very, very hard to customize. Yes, you can indeed put some props on top of it, but it's just another rabbit hole. You can't just... What you are doing here is just to brute force your logics through an infinite set of possible JSX structures. Luckily, the Chefsian and Redix already told us, by exposing the underlying primitives, even though they appear to be more complex than a fully encapsulated dialog, we automatically get a far more powerful and composable API. So let's see what's inside. So to build a dialog from Vue, the core logic is something like this. We have the handle open. We have the handle closed. We have the Vue bind tab, et cetera. And first of all, we have the open dialog, right? So we have the first components that Vue bind tab. We call it dialog trigger. Then when the dialog is now already open, we control this display hierarchy by adjusting its level by this index to 100 to guarantee it's on top of everything else. We call this layer the dialog view. It's a very normal name with just a level on top of it. The next part, if you notice, the dialog sometimes includes a backdrop. This backdrop allows you to click to close it, but sometimes it doesn't provide this ability, though. So we can encapsulate it as the dialog backdrop and with customizable props on top of it. That's to click to close. Then finally, the most important part, the content. A huge colorful view to put all your users to notice what we are going to say.

So I'm dialog. We call this part the dialog content. It will show whatever you put in this content props. And finally, sometimes if you want to put some dedicated close button to dialog so your users can easily close it, we can put it to this dialog close. Wrap them together, we provide the dialog root as the context provider. So the developers now have the full freedom to customize the component. Applying class names and inline styles is quite straightforward and it's fully supported because Lynx just supported CSS.

All the props are categorized and onto different components. If you don't want a backdrop, that's fine, you can just remove it. Or if you want to add some animation, just put it on a class name. To make you fully control the component, we even do have this, we call UI variants. It's a dynamic class name that we will append to your class name that lets you fully control what happens inside that dialog. For example, if the show is true, then we put a UI open on it. And if the show is false, then of course, the UI close.

And finally, with all that composed primitives and the class support from Lynx, and of course from native elements, we can do something even faster, that's to build your own design system. A perfect example is to build a Lunaris thing with both dark and light modes. To build a Lunaris dark thing, simply wrap your application in root with a class name named LunarisDark. The magic inside here is the single class name will provide all the necessary CSS variables for the dark thing. And here's the style sheet you would have defined.

Then we extend it to how it works on our dialog. Imagine you can get the same class name and just switch the class name on the top, on the root view of your application, and it will completely switch to the Lunaris light. In fact, we are able to scale this powerful design to the design system of TikTok. It is the same dialog we are showing you, but it's completely different on TikTok. So, by encapsulating integrity, composable structures and design into the cohesive components systems, the LYNX UI, we can be much closer to the products.

I'd like to invite Shen back again to wrap up the talk with me. Thanks. Can you hear me? Okay. Great. As always, the vision of LYNX is to give you guys, as web developers, the capability to express native use experiences. And the LYNX UI is the one more step to get us closer to that vision. So, I want to come back to this stage to give you one more update. Do you recognize the differences? It's like the motion curve. The first one is the basier and the other two is like a bit fancier. It may look subtle, but it made big differences in use experiences.

Earlier this year, we partnered with TikTok's design team to try to democratize having physics-based motion curves like spring animation across more user interfaces. In effort of doing this, we started to explore what's the best way to accomplish that. Again, you could have hardcoded everything into a native component and call that a day. But as I mentioned, we want to give web developers the real developer experiences of web. You can customize everything, you can be very flexible, everything should be programmable. If you notice that we were using native Tailwind to accomplish the design system for a native application, I think it's pretty cool. In an effort exploring this, we were able to build all these demos with LYNX. If any of this example looks a bit familiar with you, yes, they are adapted from MotionJS. I'm happy to announce that we have been able to successfully adapt the imperative version of MotionJS into LYNX. I'm also very excited to say that we started to sponsor this project since last month as well. What's really amazing about this adaption is that it's completely the same code, the same API. You basically just copy this code from Motion.js on the web, and you will be able to have the same animation render on LYNX. Even with this a bit fancier iOS slider simulation, the bouncing effect is actually created by having motion value and you add more effects to transform, blah, blah, same API again. The left video is the demo, the video designed by TikTok team. We were able to extend LYNX UI Action Ship with Motion.js to add the same physics-based motion curve.

So, you may also notice that we have been using the same theme over the whole talk. It's the building theme for LYNX UI. In fact, it's not just one theme. There are a lot of different variations. At this moment, you can tell we are really, really obsessed with design. Deep in my core, I believe as UI technologists, the ultimate goal is to deliver best product design. That's why we're really focused about it. And we believe to understand how to build great products, you need to actually dock with designs, build those design engineering by yourself, so you can have that emphasis and have that sense. This theme is called LUNA, it stands for LYNX UI Neo-Aesthetics.

You can actually express it today. So, you need to actually download app, the LYNX Go on the app store, and you then use that app to scan this QR code. It's a little bit fancier. It's, we do able to support render to the web, but this is not the version. Because we want to give you to try the native user experiences. So, shout out to Guang Yu, our design engineer, who actually crafted the whole design. And also our brand designer, Zach, who made this beautiful logo and set the tone. But definitely go follow her apps and you're going to find the same demo and QR code and how to get it done, how to try it on yourself.

And LUNA and the LYNX UI will be available in December. It will come with three platforms on release, iOS, Android, Harmony. It partially support web, because as I mentioned, there are some limitations on mobile web. And also because we are on the horizon releasing LYNX desktop, it's going to support LYNX desktop in the coming future as well. So, yeah. This is Shen and Fang, together with many LYNX UI members that's not on site with us. So, thank you for listening. Enjoy your React Advance London. Thank you.