Rewrite dashboard with modern framework

[mtrezza]

New Feature / Enhancement Checklist

• [x] I am not disclosing a vulnerability.
• [x] I am not just asking a question.
• [x] I have searched through existing issues.

Issue

We are spending quite some time on basic, fundamental bugs related to UI style, button size, scrollbars. And yet the dashboard feels and in some regards is outdated.

Enhancement

Completely rewrite dashboard using a modern UI framework where things like these come OOTB:

• UI controls don't need to be individually customized and styled
• dark mode
• responsive design
• touch UI compatibility
• UI testing compatibility

[parse-github-assistant[bot]]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

@AshishBarvaliya, @damianstasik, @parse-community/dashboard what is your opinion? Does anyone have a framework suggestion? Would anyone be anyone interested in making the first step?

[damianstasik]

@mtrezza I really like the idea, I worked with MUI a lot and I would be voting to use it as the framework. It ticks off everything on your list, has a large community and a great team working on it. I would be super interested in making the first step and trying to see how it would integrate with the current code.

[mtrezza]

Great! I assume you are referring to MUI? What do you think are the most important criteria when deciding for a framework, and how MUI covers these?

[damianstasik]

I assume you are referring to MUI?

Yes

What do you think are the most important criteria when deciding for a framework, and how MUI covers these?

I think there are 2 quite important factors:

1. How easy it is to integrate a framework in an existing app?
2. How mature is the framework?

When it comes to the ease of integration, in our case we have styles in the global scope, so a potential framework should have properly scoped styles and fortunately most of them do. Another thing would be no additional build steps, some frameworks need a bit deeper integration in a project. MUI does not need any build step mods, and should be properly isolated from existing styles.

When it comes to the maturity of a framework it means not only how long it has been available, but also what it offers. I have used quite a few frameworks lately: Chakra, MUI, Bootstrap, Blueprint, and a few more that are too fresh to mention. While I like all the frameworks I mentioned, most of the time I had a hard time to find a proper usage example, or customization description, sometimes I would be blocked by a component I thought would be available, but was not. The only framework that helped me move forward at a decent pace was MUI, it offered a big catalogue of components and the documentation was clear and up-to-date.

Now that does not mean MUI is perfect, none of existing frameworks are, I am sure each of them could bring their own bag of surprises. In my experience MUI brought less surprises than other frameworks, that is why it is my choice.

[mtrezza]

I had a look through the docs and I also find it offers a vast selection of components and seems to be well documented - with a large community.

@dblythy @dplewis do you have any opinion on this?

[damianstasik]

One thing we should be aware is that most of the modern frameworks require at least React 17 (including MUI), so we would need to check what's the current situation and focus on bringing React to latest version piece by piece.

[mtrezza]

Do you think we should build a new dashboard from the ground up, or convert the current one gradually?

• If we convert the current one, we would need to do that in small PRs, otherwise we'll always loose momentum due to merge conflicts.

• If we start a new one, it takes longer to get feedback due to slower adoption; people will stick with the old one until the new one provides all the functionality they need. But no baggage to carry over, clean code, maybe even faster / easier development because there's no legacy code to consider.

[damianstasik]

Of all the times I saw some apps being completely rewritten, paid or free/open source, most of the time it was worse, incomplete and rushed. We have a lot of complex code that could be tricky to rewrite in the new app without making some mistakes. Maybe there could be another approach, a hybrid of these two, using something like module federation? Some pages could use React 18 and new code, while others would work as expected with some components slowly being replaced by MUI one by one.

[mtrezza]

Makes sense; what do you think could a rough roadmap look like for this conversion? Keeping in mind that we prefer smaller PRs to avoid merge conflicts due to code divergence.

I would also say that the current UI layout doesn't have to be kept, there may be better layout suggestions. I would go with what the framework supports best, with as little customization as possible. That will make it easier to extend and maintain over time. Otherwise we end up again with a lot of custom code, widgets and styles as we have now where we need to dig into the CSS to keep a scrollbar visible 😵‍💫

[dblythy]

I think that a rebuild is probably a good idea. Even though it will be a lot of work, the current project is a bit all over the place, and has older relics deep in the code (such as Cloud Code Editors) that can be cleaned out.

• enforce stronger lint rules
• test driven development to reduce recurring bugs
• use modern JS syntax (the project currently uses .bind a fair bit when () => {} does the same thing

A completely fresh approach could allow us to integrate features with Parse Server easier, perhaps the ambitious one of Dashboard Users.

An overall UI refresh would be welcomed as well.

[mtrezza]

We've just reached out via Twitter to see if we have any UI designer in our community that could provide suggestions for a more appealing, modern design. I still suggest to try to stay with the framework basics as much as possible but a dashboard style guide would help us to start this off and help contributors and reviewers to keep a consistent design in future development.

[jadsonlourenco]

I agree with @damianstasik MUI is the best one, for almost all of the projects today. I think the issue will be the Table component, the "pro" version is better.

How about "routing"? I think NextJS could be included, the new approach for routing and "layouts" is good, but in beta - so, I think is better to wait until it is stable to use in production, but I think it will be released this year; also MUI doesn't work on with this new Next "app" folder for server-side components.

I don't think that is possible to have a "hybrid" without new bugs and a lot of time to fix. If is a new dashboard, with new frameworks, etc, so, is better to start from zero.

About features I think to start we need just to keep the same, changing the UI/UX for the better, as @mtrezza said.

About UI, I'm a designer, I like to design directly on the code, not Photoshop/sketch, etc, so, the result is the front-end code done at the same time. I like the current design and colors, but for mobile is not good, the keyboard shortcuts need a tutorial.

But I think the Parse project needs a little rebranding like Mozilla did to Firefox, and the Parse Dashboard a new UI, but unique. If we use MUI I think is easy to style, but I think we don't need to use "Material Design", I like more the "Ant Design" style.

So, how to help? I think we need some examples of good UI/UX os tools like DB dashboard, to inspire, then, start to design (code) the sketch.

[damianstasik]

If you suggest a full rewrite then the question is whether you have enough time to spare for a such project? While I like the idea of a fresh start, I also know what this type of commitment takes from you.

[mtrezza]

I think we need some examples of good UI/UX os tools like DB dashboard, to inspire

Yes, everyone please feel free to post any UI screenshot (ideally with link), so we can narrow down the design direction.

Maybe we can build a dashboard with more customization in mind. Every use case for Parse Dashboard is slightly different. Some may only do data correction, others may want to see user signup metrics. I wonder how complex it would be to build in a customization feature that allows the developer to define how elements of the dashboard are arranged and which elements are visible at all. Similar to a AWS CloudWatch dashboard, which can entirely be serialized into a JSON definition, see AWS docs.

Another feature that would be great would be to build a modular structure that allows others to develop extensions. Similar to the adapters in Parse Server. This way we could let others develop extensions and everyone could compose their own dashboard according to the extensions they need.

[patelmilanun]

For framework would suggest something like NextJs which is a meta framework for react or we can do it in some new framework like svelte or anything else. But I think we have bigger pool of people using react so better chance of receiving contribution from people. So NextJs would be better choice for framework.

Now about UI, it all depends on how much customized the components we want. If it's very deep in customization it makes no sense to use MUI even though MUI provides customization at some extend because it might not be enough. In that case we could use tailwind css with some unstyled, fully accessible UI component library like headless UI or even better we can use ShadCn UI which is prebuild tailwind component with styling applied with variant system. It's like creating our own library the fastest way. So to conclude MUI if not much customization and Taiwind CSS if need deep customization.

We can host NextJs on vercel and they even provide free service to open source projects. For testing we can add something like playwright or cypress to do end to end testing. We do not need to do unit testing for all of our code I guess.

Need something like prettier to have uniform styling of code.

And for approach on how to do it, my best bet would be re-writing of dashboard would be a great idea. And if possible as @damianstasik suggest some hybrid approach where we re-write dashboard while keeping old dashboard code. So slowly moving from old code to new one. So for example we can start implementing new UI on sidebar first. Then top bar. Then data table itself. Something like that. As writing from scratch needs dedication.

What do you think @AshishBarvaliya about this.

[mtrezza]

If we'd aim for a developer-customizable dashboard, where they can enable / arrange widgets and they can add optional extensions, would that require a rewrite from scratch or is that also possible with a gradual framework migration?

[jadsonlourenco]

So to conclude MUI if not much customization and Taiwind CSS if need deep customization.

MUI has the Base UI https://mui.com/base-ui/getting-started/overview/ And the Joy UI https://mui.com/joy-ui/getting-started/overview/

I think both frameworks are good for UI, and even if the framework has some features like the "grid" I preffer to use the native Browser feature.

[patelmilanun]

@jadsonlourenco you are very right about using unstyled components but the main reason I prefer tailwind is that we can write css faster which boost productivity. We can use this component which are unstyled and provided by MUI along with tailwind css. I'm just suggesting tailwind just becuz of speed at which we can move forward.

[AshishBarvaliya]

If we'd aim for a developer-customizable dashboard, where they can enable / arrange widgets and they can add optional extensions.

Are you suggesting that we should create separate libraries for widgets, allowing users to add new designs if desired, while still being able to continue with the existing design if they prefer? If that's the case, it seems feasible to proceed with the current repository instead of starting from scratch. However, we should still address any outstanding issues in the old repository to ensure proper maintenance.

[jadsonlourenco]

If the Parse Dashboard has this level of customization will be a new dashboard, and making it flexible to a lot of cases will be hard to maintain, including styles possibilities... So, Parse Dashboard will be not only a DB dashboard? What is the target?

One example of customization, and a "flexíble" system base to have a "unique" style: https://www.youtube.com/watch?v=A4oNA05OaIE Adobe Express did the same, but to generate banners, etc. without AI.

About using the current repository and "merging", If we have a new sidebar with React 18, and the topbar with current React 16 (both are always present on all routes), will it work?

[mtrezza]

Are you suggesting that we should create separate libraries for widgets

I'd think of it like VSC extensions. These extension don't change the visual style of the VSC editor, but add new functionality.

For example, to change which widgets are displayed on the start side of an app. Currently it's the data browser with a nav bar on the side. But it could be a grid of widgets instead. For example a graph widget that contains a custom server query to define what should be displayed. And the data source doesn't have to be Parse Server, it could be any REST API. We'd just have to define the required data structure of the API response. This would make the dashboard super versatile and could encourage dashboard widget contributions.

[jadsonlourenco]

Like Metabase? https://www.metabase.com/ Also, Metabase is open source: https://github.com/metabase/metabase

[mtrezza]

Yes, good example; Parse Dashboard is of course more than a data explorer / visualizer. It's also a data manipulator (Cloud Config, data browser) and a workbench (API console, push notifications). I could imagine that there could be:

• non-customizable pages such as for push notification, cloud config, or API console; these are pages with complex functionality where UI elements interact with each other; each of them could be a widget as a whole, filling a page.
• customizable pages such as the start page of an app where widgets can be added / arranged; we could provide a few simple metrics widgets OOTB (such as a graph or number display), and display some basic metrics (number of classes & objects), users sign-up per day over the last month; then users can add more pages as needed e.g. a page dedicated to user sign-up & retention, another for push notification metrics; this could leverage (and revive) the Parse Server analytics module.

The current Parse Dashboard looks the same for everyone. That I think is one reason why it's still so plain; it is reduced to the least common denominator. If we allow others to contribute widgets (directly to Parse Dashboard) or in their own repository so they can be imported, we could stimulate future development and developers could use these widgets to build custom dashboards that are more useful to them, tailored to their use case.

I guess the key for this would be finding a framework that supports such a functionality. If that is all too complex, then a rewrite for a more modern, static (non-customizable) dashboard would of course be an improvement as well.

[mtrezza]

In conclusion, which framework do you all think makes most sense to use when rewriting? Once we agree on a framework maybe we can set up a roadmap and start assigning bounties to each of the tasks.

[patelmilanun]

I know you have so many great ideas for the new dashboard. Looking at the contributors for this project we should keep it simple. The purpose of re-writing would be making it contributor attractive meaning using better, newer and popular framework. This should make the code more maintainable and attract the new contributors as it is using latest tech.

Doing this should improve the performance as well and give end user a new modern and minimal feel.

As I mentioned in my previous messages here, I think Next JS + MUI would be great choice. But be aware that if there are so much customization from the design side, we should use something that is basic un-styled and use tailwind like library to customize it. This way it is fast, and we are not fighting with MUI to get something specific (I know this pain)

[mtrezza]

I'd leave the framework decision up to your consensus. What does everyone think about Next JS + MUI? And is that a framework that you're familiar with where you would be able to continue to contribute?

Maybe we can just keep the custom graphs / metrics feature in mind for a future feature addition, like in a separate new "Metrics" page. So we can just focus on modernizing the framework for now. I think visualizing custom metrics could be a significant feature for Parse Dashboard, but it shouldn't hinder the rewriting if that makes it all too complex.

cc @davimacedo, @parse-community/dashboard

[baibhavKumar1]

@mtrezza , is there any update? If no, where will I find the update whenever it will be updated? Thanks

[mtrezza]

Not sure what you mean. Any updates will be released as usual. If you mean you want to contribute to this issue, feel free to engage in the discussion and /or pull requests.

[mtrezza]

In conclusion:

• We'll use Next JS + MUI, which gives us less customization freedom but we want to avoid over-customization anyway, which is one of the current pain points of the dashboard that introduces bugs and inconsistencies in the UI.

Open question:

• a) Looking at the current features of Parse Dashboard, can MUI cover all the necessary controls?

• b) Can we rewrite the dashboard in this repository so that a user can switch between the current and new framework? The idea is that we will get quicker feedback if we don't open a new repository to release a separate app. The idea is just a simple switch that allows to use the new dashboard with reduced functionality and we add an "experimental" note to it. We may not need to mix the 2 frameworks and just offer the new dashboard with reduced functionality at the beginning. But maybe once we have a stable base we could implement pages like "Push Notifications" or "App Settings" that are using the old framework and embed/link them in the new framework, so we offer an easier transition to users.

• c) Do we have any UI designer among us here, or how are we going to define the UI? Some simple mock ups could be a helpful guide for contributors. Or does MUI have a best practice suggestion for responsive design?