With Fusion’s popularity on the rise and suggestions for a Roactify-like plugin for Fusion I decided to create this UI to code converter plugin. Fusion is still in beta so this plugin may change if any major changes are made to Fusion, however the core principal works just like Roactify; The plugin will generate a LocalScript or ModuleScript containing the Fusion tree of the UI that you converted.
Hydrogen is super simple to use:
Configure the settings for the place before converting a UI
You should add the reference to the Fusion module in your game. If not provided the plugin will attempt to find it in common places but it is not guaranteed that it will be found.
You can provide a reference to the instance that you wish for the resulting scripts to be parented to. If not provided an output folder will be automatically generated.
Configure the format settings of the output scripts to your liking.
Select the GuiObject that you wish to convert to Fusion code.
Press the “Convert to Raw” or “Convert to Component” button in order to generate the corresponding script for the GuiObject you selected.
You will see the generated script selected in your explorer window.
Warning: This plugin has not be tested on larger UIs and it is recommended that you don’t convert a large UI tree into a single script. You should generate smaller separate component modules and then manually construct them together to make the whole UI.
If you find any issues while using this plugin please make a new issue at the provided repo so that the issue can be looked at and resolved! Also if you have any feature suggestions that are relevant to the plugin do feel free to create a suggestion.
When you have a big experience/game, every UIs can be hard to manage and kept track of. Having a coded approach helps you make them more organized and clean. Sometimes they can become virtually impossible to maintain and just creates useless clutter. But I guess everyone has different reasons/expectations so it’s all depend from there.
I guess each people has their way of designing or programming, there isn’t a sole correct way of doing so. By saying the future of UI is bright I mean that it gives more opportunities and diverse other ways to design UI to our likings.
Like @Synthesz stated, everyone has their own way of coding their UI. However, declarative UI libraries make managing UI that much easier. They allow you to update and manage your UI state with super simple code, and they remove your worry of having to deal with specific edge cases when you need to disconnect events or manage user input.
You don’t always see the benefits of them at first until you start using them and realise that you have wasted so much of your time creating UI code that could be made in mere minutes with these libraries.
Here is a great tweet from kampfkarren that outlines a lot of the benefits for Roact (same applies for Fusion and other declarative libraries)
At first it will be much slower than your usual UI creation, but that is just all down to the fact that you are learning a new thing! You will also have to create all of your components from scratch, but once you have them made you will be able to make a UI with ease.
A lot of people then come back and say “This is even more time consuming because I have to run the game everytime I want to view changes to my UI!”. No you don’t! We have a plugin for that, it is called HoarceKat, it allows you to view changes to your UI code in real time!
I hope I convinced you of the benefits of these libraries and how they make UI development easier for us. Either way, thank you for reading.
a lot of companies that use declarative UI libraries list one of their main reasons as being able to manage their codebase in a version control system like Git easier
I might be biased as the creator of Fusion but the entire reason I spent two years developing it as a research project was not to make my own UI code less maintainable
It’s perfectly alright if it isn’t for you, but please be mindful that other people may have other motivations for why they prefer to develop a different way!
Within my own code, I’ve found that it helps me to compartmentalise my UI into reusable blocks in a way that’s currently frictionful with regular instances, and helps naturally integrate data with UI - something that’s important for the data-heavy UIs I tend to author as a plugin developer.
It’s worth mentioning that prior to Fusion, I did exclusively stick to the Roblox API and avoided most libraries - I still prefer to work ‘close to the metal’ for most things, since Roblox is indeed very capable, but I have special unmet needs when it comes to building complex, animated, data-driven UI. That’s the big use case I originally built Fusion to answer
If you’re willing to entertain a 10 minute video, I outline the basic surface-level concept of Fusion here - perhaps it may help foster some understanding or at least some curiosity! Thinking In Fusion - YouTube
Not every tool is right for every project, and it never was. Your needs are not everyone else’s case by case.
If every tool was meant for every situation we wouldn’t be having JavaScript frameworks made every hour of the day.
Every game has different needs, every developer has different preferences - hell - use both premade and code only UI elements - it’s up to you how to use a hammer and a nail.
I was previously trying to transcribe all my game’s UI into Fusion by hand. I wish I’d known about this plugin earlier, it makes things so much easier.
