Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Future of Lydie #1

Open
7kayoh opened this issue Apr 26, 2024 · 5 comments
Open

The Future of Lydie #1

7kayoh opened this issue Apr 26, 2024 · 5 comments
Assignees

Comments

@7kayoh
Copy link
Owner

7kayoh commented Apr 26, 2024

The purpose behind open sourcing Lydie is to provide developers with a comprehensive set of components, thus eliminating the need to expend time reinventing the wheel for trivial tasks, such as creating small plugins.

Created 2-3 years ago, it was originally used for building the interface of Frappé's future games and toolkits. Powered by Fusion and FusionRouter, it is a powerful component library with features such as hot theme switching.

Lydie is outdated in terms of supporting new Fusion versions and leveraging the latest UI enhancements from Roblox. To ensure its relevance in the future, some actions must be taken to refresh Lydie, rendering it at least future-proof for the next several years. This could entail either extending the existing codebase or developing a new iteration with a similar architecture, ensuring a smooth transition for existing users. Notably, Lydie was developed prior to the introduction of Automatic Sizing, resulting in many components, particularly the button class, necessitating manual resizing to accommodate text strings. While not a significant issue, this inconvenience can accumulate over time, contradicting Lydie's objective of facilitating rapid UI development.

Here are my plans for the next version of Lydie.

Name Description Action
A new design language Lydie was exclusively crafted within Studio without any of the iterative designs or prototypes, leading to inconsistent styling across components and a messy architecture that impedes component extensibility (e.g., integrating tooltips with buttons). A comprehensive design system must be created before any code alterations for the next Lydie version, ensuring consistency and facilitating future contributions. Before touching the code for the next Lydie iteration, a robust design system must be established to govern the styling of all components. This approach not only addresses existing issues but also streamlines future development efforts by promoting greater consistency.
Support for Fusion 0.3 Fusion 0.3 introduces numerous enhancements, including scope and contextual features. Given the constraints posed by 0.2, reinventing fundamental functionalities (e.g., theming system i.e. contextuals) seems impractical. Transitioning to Fusion 0.3 offers several advantages, enhancing Lydie's robustness and future-proofing it against upcoming developments. Improving the existing codebase for the next Lydie version would require rewriting or modifying most components and libraries to align with Fusion 0.3 specifications. Replacing the schemes library with a simplified Contextual object and rethinking how components should be with the deprecation of Hydration.
Making use of Roblox's new features Lydie predates features like AutomaticSize, Flexible Layouts & Flex Items, AutomaticCanvasSize etc, and cursor scrolling for TextBox. Consequently, many components lack sophistication compared to recent libraries. Adopting these features into Lydie can significantly enhance its capabilities and competitiveness. Enhancements involving rewriting certain components to support new features are necessary. For instance, custom cursor scrolling in TextFields may be replaced with native implementations, contingent upon stability assessments.

While additional enhancements may be needed for the next Lydie iteration, the aforementioned represent the primary goals right now. Due to university and jobs, this will be carried out only after university break hopefully. Feedback and suggestions on these proposed initiatives are welcomed for further refinement.

@7kayoh 7kayoh self-assigned this Apr 26, 2024
@7kayoh 7kayoh pinned this issue Apr 26, 2024
@ChrisvanChip
Copy link

Stumbled on this repo last week, it looks really promising! This library would help me creating in-game debug UIs, custom moderation workflows, basically anything back-end related without sacrificing too much resources (or having bad UX).

To support these use cases, it would be helpful if Lydie had components like Typography (Title, Subtitle, Label) and Cards.

e.g:
image

Are components like these planned with your new design language?

@7kayoh
Copy link
Owner Author

7kayoh commented May 31, 2024

Typography classes will be planned, but I need to think how they should be implemented nicely, in a style like markup languages

@7kayoh
Copy link
Owner Author

7kayoh commented Jun 28, 2024

Some progress to Lydie V1.0 (the version supporting Fusion V0.3) is being made, this will be a 100% redo because I find the current code structure a little bit horrifying to look at. This means everything in 0.1 won't work with 1.0.

Changes so far:

  • Categories
    Rather than Controls and Views, we are renaming the categories and creating a few new ones: Containment, Navigation, Inputs, Feedback, Images, Pickers. This makes components more organized and actually reflects the name of the category they are in.
  • State-first
    All components are state-first by design, meaning properties should be using state (Fusion.Value) instead.
  • One button
    Right now, there are like 4 types of different buttons, base button, button with text, button with icon and button with text and icon. In V1, this will be replaced with 1 single button named Button, you will be able to inject icon either by prepending it or appending it (PrependIcon/AppendIcon), or use icon only by supplying the Icon property only.

Proposals:

  • Directives
    We want to create some sort of directive implementation in Lydie, so it will make things more easier to deal with, especially adding tooltip to buttons. It could be done using a key like [Lydie.Directive "Tooltip"] = scope:State("Tip!").
  • Scope for theme
    Right now, theming is handled by a module, this is totally fine but creating a new theme would mean the developer need to fork Lydie and add their own theme file, sorta. We honestly do not want that to happen because developers will have to spend some extra time syncing their Lydie fork to the new version while keeping their changes. In V1, it would be nice to have the current theming system deprecated in favor of a Scope-based theme provider. For instance:
    local scope; scope = Fusion.scoped(Fusion, Lydie, {
      Theme = scope:State({
        Value = "MyCustomTheme",
        Colors = { ... },
        Variables = { ... },
      })
    })
    
    Button(scope, { ... })
    This is somewhat similar to the ThemeProvider in Vuetify, except this will be handled by the scope and not Lydie itself. Developers can create custom themes by adding a dictionary member to the Colors/Variables dictionary, i.e. MyCustomTheme = { ... } -- color goes here.

alicesaidhi referenced this issue in alicesaidhi/kibble Jun 29, 2024
@7kayoh
Copy link
Owner Author

7kayoh commented Jun 30, 2024

  • Directives
    We want to create some sort of directive implementation in Lydie, so it will make things more easier to deal with, especially adding tooltip to buttons. It could be done using a key like [Lydie.Directive "Tooltip"] = scope:State("Tip!").

Changed how directives work by a bit, instead of calling Lydie.Directive with the directive name, we are letting users to index a metatable under Lydie.Directives, which will give a SpecialKey (Directive) containing the directive function in return.

local Directives = Lydie.Directives
local TooltipDirective = Directives.Tooltip

New "TextLabel" {
  [TooltipDirective] = "Hello world!",
}

@cosinewaves
Copy link

Converted src to a .rbxm
lydie.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants