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?

[mtrezza]

Does anyone want to take the lead on this? We could try to allocate a budget for a lead developer and coordinator of the framework rewrite.

[AshishBarvaliya]

I'm not sure about leading the project, but I'm happy to assist with decent availability if anyone else wants to take the lead.

[patelmilanun]

I can take a lead on this.

First step we need to figure out is how we want re-shape our dashboard. And need to figure out exact features we can have for our new dashboard. We can finalize exact tech stack later along with what libraries is suitable with its purpose.

We need to list down them accurately so that we can have our designer design things accordingly.

@mtrezza can you start with new thread for the listing of points and the ones which you think are required for our first release. 1 more thing, we need to have a separate project for the v2 of dashboard as we are changing whole framework.

[patelmilanun]

I'm thinking of design like pocketbase and supabase table editor.

[mtrezza]

Great!

I've created a project so we can better organize. As a first step I'd suggest to collect feature ideas here in this thread and if they make sense add them to the project where we can prioritize them. Everyone has read access to the project, but currently only you @patelmilanun have write access. We can expand write access for everyone who wants to be more involved.

Once we start with development, we could create a separate branch for this and once the new dashboard has a reasonable amount of features we can merge it into the alpha branch and maintain to the old dashboard as legacy branch for a while. A better solution may be to develop the new dashboard in parallel to the old dashboard and let users switch between the new and old dashboard with just a click, so it doesn't require a separate installation and we'll get much more feedback more quickly, and possibly see more contributor activity.

[mtrezza]

I'm not sure how complex it would be, but I think that the best dashboard adapts to the use case, on an app and user level. Parse Dashboard is used slightly differently for every app and by every user. Therefore a customizable dashboard would bring the most benefit for all users. I imagine a dashboard where a developer can design pages with different UI widgets (data table, graphs, form fields for data entry, etc.). Then, a dashboard user gets access to individual pages based on their role and the tasks they perform in the dashboard. Something similar to Retool.

For example:

• A content moderator sees a page with a large image view and buttons to accept or reject content. The buttons trigger Cloud Functions to execute the content moderation. The objects that are to be moderated are retrieved via a request sent to a Cloud Function.
• A supervisor sees the page with graph elements that show the statistics of content moderators.

It could allow developers to write their own add-ons, similar to Parse Server's adapters, which could stimulate developer contribution. We also don't have to limit it to Parse Server, it could support any HTTP requests and therefore be useful for many applications outside of Parse Platform. This could bring contributions to the project and also attract new developers to Parse Platform.

[patelmilanun]

I think we are positioned as dashboard for parse server thus the name parse dashboard. If we want to make something like retool or refine.dev (open-source alternative to retool), we need to change the branding of it. And then we are in competition with those big giants who already have ecosystem and contributors.

We should keep the scope to the parse server only for revamp of dashboard. Anyone wanting to have features you mentioned can opt for those big giants. We may provide a guide or plugin that match with their ecosystem instead of competing with them.

Right now, we are in business of parse ecosystem meaning we should focus on extending support for parse server with SDKs, integration guide, one click deployment button, dashboard.

Because of this I suggest aiming for adding accessibility which was missing since start and better contribution support by adding things like typescript and using newer things for development.

And as we are adding above things, we are revamping whole dashboard's look and feel so it can be more aligned with modern design.

[mtrezza]

Is there no middle ground in which we can provide a dashboard with more flexibility, like for the example in the use case I've mentioned above, but not on a low code level like refine.dev?

Parse Dashboard currently is mainly just a raw data browser. It's more of a development or maintenance tool rather than a tool for operation. The pro is that it's easy to deploy, no development, only configuration. On the other hand, for a developer using frameworks like refine.dev means building a dashboard from scratch, which provides the most flexibility but requires the actual development of the dashboard, which requires more effort than just setting some configuration.

Take for example a AWS CloudWatch dashboard. It has only a few basic widgets and you can define the positions of them and their data sources. The config of the dashboard widgets and layout is pretty simple, see docs. But I guess we'd need to find a framework that supports a dynamic layout that can be defined on launch instead of hard coded. If there isn't any, it may be too complicated and we should probably just stick with the primitive data browser we currently have.

[wujianguo]

I'm not sure about leading the project, but I'm happy to assist with decent availability if anyone else wants to take the lead.

I'm also happy to assist with decent availability.

[patelmilanun]

Let me think and figure out a middle ground.

[mtrezza]

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

[jadsonlourenco]

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]

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:

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

[mtrezza]

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?

[patelmilanun]

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 💪

[mtrezza]

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]

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.

[patelmilanun]

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

[patelmilanun]

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.

[patelmilanun]

Found it. We could use https://github.com/szymmis/vite-express which basically hijack our express app and inject vite development server. This means we will be getting output like this

And if we change the file then

Is this ok @mtrezza ? If yes I can push and raise draft MR here

We can even use the same coloring library to match the console output of vite