In my day-to-day work, I’m a full-stack developer, so I’m familiar with React. I wanted to integrate React-Lua into my game.
The thing is that debugging/testing the code that I write is not a fast process, because there is no react-refresh (as far as i know), i tried using tools similalr to storybook, but if i inject some logic to my component that the storybook doesn’t know to handle it crashes my story (and sometimese its unavoiadble, as i want to develop fast).
This is how I see the pros vs cons of using React-Lua
pros:
easier to manage state
Conditional rendering based on states
contextes, etc…
Cons:
not a fun process creating the UI, styling it, etc… (because everything is in code and hard to debug)
Small adjustments are just easier to do in the Roblox Studio UI editor instead of code
If you guys have any tips, I would love to hear them!
I’m curious about this as well since my testing workflow consists of making changes, running game, checking results and repeat which is pretty tedious.
What tools have you used? From my quick search, I found Flipbook and Hoarcekat which look promising.
I’ve never used these frameworks so I’m not unfamiliar with their common issues. What logic are you injecting that is causing them to crash?
For example, when I wrap it with context (this is solvable by wrapping the story with the context as well).
Also, when I use knit, knit is not being initialized when I run the story, so it doesn’t know what to do and crashes
So you’re referencing Knit in your react components right? If so, is it possible to somehow initialize Knit before any storybooks run? I’m assuming this probably wouldn’t be a straightforward thing to do though.
My best suggestion would be to completely isolate your UI from the rest of your game systems and logic. For example in one of my projects, I set up a sort of MVC architecture for my UI.
The only thing the react components care about is the UI state. They react to changes from the state and will forward UI events (button clicks, certain key presses, etc.) to the state. They don’t know or care about what is actually controlling the state so there’s no dependency there. The UI controllers are the ones that actually communicate with the game systems and frameworks. Events from game systems are detected by the controllers and logic is ran to change the UI state accordingly.
In this situation, I’d probably make a sort of mock controller that provides fake (but realistic) data and has basic functionality to handle the UI events.
In your case, this might be easier said than done depending on how interconnected your components are with Knit or any other game logic you have. It might not even be worth the refactor but that’s something that you’d have to decide yourself. However, I believe a design like this would allow you to use these storybook tools without much of an issue since you can provide the bare minimum (UI State and a mock controller) in the storybook and the components would function the exact same.
This architecture looks interesting. Do you have a code example for that? (even though MVC is kind of not the best practice anymore), But in any way, what are you getting from React if you are using those “UI controllers”?
I can probably do that, but as you said, it will take some time, and in my case, I want to develop fast… and it seems like it’s just making things harder for me.
At the end, I like React because of the state management and the life-cycle itself: when the state changes → do something (just like my web dev experience).
But in terms of creating the UI itself, it’s just not comfortable, every component I need to specify several “native” props like: Position, Size, etc (even if I make reusable components), Where when I use roblox studio’s UI editor its very easy to create and position stuff but then I lose the state managment of react…
At the end, I’m trying to find a sweetspot, to enjoy the reactivity of React but not go “insane” because of the struggle of designing and building the UI with code
