I’m fan of Daishi’s other work (like Zustand and react-hooks-global-state) so I’m intrigued to see this drop. As a longtime Next.js fan it’s cool to see simplified versions of new tech emerge.
I used Tamagui to build a number of screens for a new product we're working on, and I saw 90+ lighthouse scores on every page. The fact that I can get that, with SSR support, inline styles, psuedo selectors, typed themes, and that it works on iOS and Android is novel.
I built the first library for React Native that supported Web/responsive design (Dripsy), so it's cool for me to see Tamagui taking this idea to the extreme.
Tamagui basically solves the part of styling + rendering UI. It works on both web and native.
As for logic/data fetching...this has gotten far, far better in React over the past few years.
For data fetching, assuming you're using REST, @tanstack/react-query is incredible. It gives you a "hook" to wrap any async function, and returns loading states, errors, etc.
In the past, people used Redux, but it's out of fashion now. I prefer a library called zustand whenever I need non-data related global state management.
I would definitely disagree with "Redux is out of fashion". Redux is still by far the most widely used state management lib with React apps, by a very large margin - my estimates are that 35-40% of React apps use Redux, and no other state management lib appears to be over 10% [0].
We also get a lot of very positive feedback on our modern Redux Toolkit package, which we designed to simplify Redux usage [1], and it includes our "RTK Query" data fetching and caching API as well [2], which is similar to React Query in use case and API.
Mostly things that are very widely used in industry are indeed no longer “in fashion”. Instead they were in fashion and actually proved valuable enough to have staying power (as opposed to most fashionable things that are junk). Charitably, anyway — sometimes it seems you can’t tell why something is still widely used.
Probably the mentioned hooks-based approaches are indeed fashionable now. Remains to be seen whether they’ll stick around.
My team at work has completely rewritten from Redux with Redux Form to Tanstack query and React Hook Form over the past two years, and we don’t miss a single thing about Redux.
We make an app that contacts lots of microservices in sequence and combines the data in many ways. Having automatic refetching, caching and the like by default makes a world of difference.
I don't know if it's still the case but when I started my career (granted, some decades ago) using the new hotness X/Motif + C++, there were still more lines of COBOL around than anything else. (Hell, might not have been the case then, but that was the yarn.)
RTK Query is an excellent package! Coming from the React Query world, I inherited an RTK Query project and was initially disappointed, but have come to prefer it over (the also excellent) React Query.
Tamagui for "View" components and styling (+SSR on web)
+ React Query for data fetching, cache management, and neat hooks to use that data in apps. (+SSR on web
+ Zustand - "lite" state management on RN and React Web
+ Moti for X-Platform animations
+ Zeego for X-Platform menus
= Ridiculously high percentage of code re-use across web and react-native apps.
We're glad you liked the idea! I had this idea in my head for about 2 years until I met Sebastian and we decided to give it a try!
We already support sending GraphQL queries and validating the responses
Soon we will also be able to generate automated API tests based on your GraphQL Schema. You can watch our main repository (https://github.com/stepci/stepci) or subscribe to our newsletter to follow our progress!
React Native + Next.js refers to using the same code in both a native app and website (built with Next.js).
The hardest part of sharing code between apps and websites, however, is the navigation code. Websites have flat navigation. You have one page mounted at a time. When you navigate to another page, the original one unmounts and a new one renders.
Native navigation has a different paradigm altogether. Rather than use simple URLs to account for most of the navigation state, native apps have complex tabs, stacks, and more. When you change tabs on Spotify, you expect the previous tab to maintain its state, scroll position, nested screen, etc.
Given all of these considerations, it's previously considered impossible to use the same code for apps and websites, even if they're all written with React.
Solito solves the navigation problem by offering a unified API across Web and Native. This lets you write your code one time with React Native, and use it on both iOS, Android and Web.
From the docs:
> Solito treats URLs as your source of truth. Your Next.js app and React Native app don't communicate at all. They live in total isolation. Solito works by doing this: give me a URL, I'll detect what platform you're using, and then I'll figure out how to navigate to the screen for that URL.
I don't view a single codebase as the goal necessarily. While I see the benefit to doing a WebView everywhere, I prefer the React Native approach: write once, run anywhere by using the underlying native components of each system. Because it has such a great unified API for building UI, React Native is a good abstraction to use the same code everywhere. But what draws me to it is the fact that it maps onto native elements.
That said, I'm sure there are good arguments for Capacitor!
Those kinds of implementation details won't be hard to add to Solito. The API I'm using is that of Next.js. If they adapt to suspenseful approaches to routing, Solito will too.
That's fair, you're limited by the technologies you're using. I guess that's a problem with these sorts of libraries, you can find yourself being "the lowest common denominator". Of course, your library is very useful, and there are plenty of apps that I imagine can just drop in Solito. So this isn't at all to detract from its real-world value today.
However, as much as it's convenient to get up and running (with bundle splitting), the file-system based router is in my opinion probably the weakest part of Next.js. It would be top priority on my list of things to go. The main issue is it's fundamentally not type safe.
For example, Solito's useParams() is fragile because refactoring can easily cause param substitution to come out of sync with param consumption (in another component). My most recent solution (not in Next.js) for this is:
