Search code, repositories, users, issues, pull requests...

New Feature / Enhancement Checklist

I am not disclosing a vulnerability.
I am not just asking a question.
I have searched through existing issues.
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.

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

Thanks for opening this issue!

🎉 We are excited about your ideas for improvement!

added

MemberAuthor

@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?

pinned this issue

on Jun 11, 2023

Contributor

@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.

MemberAuthor

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?

Contributor

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:

How easy it is to integrate a framework in an existing app?
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.

MemberAuthor

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?

Contributor

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.

MemberAuthor

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.

Contributor

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.

MemberAuthor

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

Member

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.

MemberAuthor

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

Contributor

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.

27 remaining items

MemberAuthor

Great, otherwise we'll just go with the framework modernization and keep the dashboard functionality more or less as is.

jadsonlourenco

Contributor

I think Parse Dashboard should have by default all features that Parse Server has, maybe a GUI to use Cloud Functions, etc.

With this new V2 Dashboard could have a "plugin/widget" feature, that we can use the EMS module to "import" in configuration to fast deploy. So, we can have a plugin to show "count numbers", in the dashboard by default need to set "spaces/areas" to load these plugins/widgets.
In this way the Dashboard doesn't have a lot of complexity to maintain, we don't need a new WordPress, hahaha.

So, I think the Parse Dashboard is the GUI for the Parse Server. If a developer needs a dashboard for a specific project cold use it with a "plugin", create the plugin, and load it into the Dashboard. But, for example, how to handle the "Parse Classes" permission? So, the Parse Dashboard needs ACL for these "plugin areas", or directly for each widget. But, I don't think we have a better option to have a "flexible dashboard" that can handle different types...

Looking at Retool seems like they give the developers a framework, with a lot of GUI components "done", using MUI, that can handle a lot of dashboard types... integrating with the backend to fetch the content. I have a private framework like that, like:

<MyTableParse
  showPagination
  headerBorderBottom
  isOffline={false} // offline support of Parse Server
  itemsPerPage={10}
  Item={TableItemMessage} // Each table needs to have a different Row design (component)
  itemProps={{ // Row component props
  showName: true,
    handleEdit: () => {},
    handleCancel: () => {},
  }}
  parseQuery={{ 
    class: 'ClassName',
    include: ['PointColumn'],
    limit: 10,
    saveResultToLocal: true, // Save the results to work offline
  }}
  // Sort query by default (could be in the parseQuery param, refactor)
  sortDefault={{
    column: 'updatedAt',
    order: 'desc'
  }}
  // GUI to sort with one of this column
  sortsParams={[
    { title: 'Label', column: 'columnName' },
    { title: 'Label', column: 'columnName'}
  ]}  
  // Select each row, or all, 
  selectParams={{ 
    column: 'objectId',
    class: 'ClassName',
    selectListTitle: 'LabelButton',
    selectListTableColumns: [       
      {
        field: 'enabled',
        headerName: 'Ativado',
        type: 'boolean',
      },
      {
        field: 'name',
        headerName: 'Nome',
        flex: 1,
      }          
    ],
    actions,
  }}
  searchParams={{
    column: 'name',
    fullText: true
  }}
  // GUI to filters have many types of filters: string, boolean, before/after date, etc.        
  filterParams={[
    { column: 'columnName', columnTitle: 'Label', type: 'select', options: [ 
      { title: 'All', value: undefined }, // First select item, need be undefined
      { title: 'Label', value: 0 },
      { title: 'Label', value: 1 },
      { title: 'Label', value: 2 },
    ]},          
  ]}
  // MUI Button to "filter" by "pointer column"
  filterButtonParams={{
    class: 'PointerClassName',
    include: 'IfNeedOnRowComponent',
    filterTitle: 'ButtonLabel',
    columnData: 'createdBy', // CUrrent Class column of Pointer
    columnTitle: 'name', // Column of Pointer to show in the select button, the label
    column: 'objectId' // Column of Pointer to query
  }}
  // MUI Tabs
  tabs={[
    { title: 'All' },
    { title: 'Label', column: 'columnName', value: 1 }
  ]}
  // Table header button, like to ADD new entry
  buttonParams={{
    href: '/add-route',
    title: 'Button Label', // HTML <a> title
    icon: <AddCircleOutlineIcon />, // MUI icon
    text: 'Button Label'
  }}
  // MUI Paper component props
  paperProps={{
    elevation: 0,    
    sx: {
      marginTop: 1,
    }
  }}
  // Header of the table props
  headerProps={{
    sx: {
      paddingTop: 0,
    }
  }}
  // HTML <ul> props
  listProps={{
    sx: {
      flexGrow: 1,
    }
  }}  
/>

Demo:

So, the third-party plugins/widget projects could work with Parse Dashboard, to make it "better" for each use case. So, we could create a new Project to these GUI components that integrate with Parse Server and run/load in the Parse Dashboard, and have a React/Next/MUI base, out of the Parse Dashboard, like parse Server has few "modules" out of the main project.

AshishBarvaliya

Member

I believe it's a matter of convenience regarding how much progress we aim for, or perhaps it's simply a matter of taking the initial step and then proceeding incrementally. Here's a breakdown of the ranked complexity from low to high:

Implementing a straightforward dashboard modernization within the same package, offering user choice.
Introducing a visualization dashboard akin to CloudWatch, with limited customization options.
Developing widgets with complete customization capabilities.
Implementing an ACL/Role-based widgets dashboard with more features.
Enabling third-party integration
... and more

MemberAuthor

Is there a framework that can be used for such an incremental development, that covers all these capabilities, without being too low-code to make development easier?

Member

As I said earlier, we should stick to the scope of the project and focus on revamping of dashboard. Other things like extension or widgets can be added later if we successfully complete this revamp.

There is no exact framework which fulfill all our need or most of the need. With react we can customize as we want. This means in future we can extend our app's capabilities to add things like extension or widgets support. When we do want to add it in future, we also need to count the requirement of this features. Like do we really need this feature!

By looking at everyone's current availability, I can say that alone revamping of the dashboard is big task because in this revamp we will be adding existing feature from old dashboard, basic missing feature as well as few important features from the feature requests.

Right now, our priority is to have a POC ready with existing repo (we may need to change few bits) such that user can switch between new dashboard and old dashboard for the instant feedback. This will make the development incremental.

So, without further ado we should initiate the process now. Let's do it 💪

MemberAuthor

Could we at least add a PoC for a customizable dashboard page early in the roadmap? Even if just in a very rudimentary form. So we make sure that the approach we are using allows to add the feature in the future without major rewriting. We surely don't want to invest resources now just to have to discard large parts of the code in a couple of months. I may be wrong, but to me, this feature sounds so fundamental that it may have a lot of influence on early design decisions.

What do you think about using a framework like refine.dev? Any pros / cons?

AshishBarvaliya

Member

I'm currently developing a proof of concept (POC) using TurboRepo, which involves two mentioned applications. The goal is to build three apps: an old dashboard, a new dashboard, and a server. Based on configuration variables within the server, we'll determine which dashboard to utilize. Importantly, both dashboards will be independent of each other in terms of code dependencies, facilitating the removal of the old dashboard if necessary in the future.

Regarding creating pull requests (PRs) for this work, I'm hesitant as around 95% of the code will undergo changes, potentially causing all associated jobs to fail.

Feel free to share your thoughts or suggest any alternative solutions you might have in mind.

Member

@AshishBarvaliya any progress on the monorepo. Do you need any help with anything? Let here know if you want anything specific.

Member

I have created a PoC with vite react project. I'm able to integrate this new vite project into our existing project without too much of breaking change I guess. I will post the repo shortly.

I have 1 blocker though, right now if you see we don't have HMR(hot module replacement) meaning the changes we do most of the time will be updated without refreshing the page. We do have the concept of rebuilding the build on file change but we need to do the manual refresh of page every time something is changed.

The same problem exist in this setup as well. Basically I'm watching for change and build the app again and output it to the specific folder if there is any change. This folder then be served as static asset via our already running express server.

But that is what causing HMR to fail. Usually in vite dev mode, it spins up its own server and enable HMR but the same is not working in custom express server. I have tried few things but with no luck.

So, anyone here has done any such things or know how to do it please let me know.