Refining Dify's Frontend: Enhancing Development Practices for Better Collaboration

[TinsFox]

Hello there, I'm TinsFox, a frontend developer. Recently I've been reading the frontend code of Dify, planning to contribute to it! But before I start, I have noticed some minor DX pain points, and thus I wrote this document to discuss them with you~

I'm just a beginner, so please enlighten me if I misunderstand anything~😉

Table of Contents

1. Introduction
2. Do We Need Next.js?
3. About Data Fetching
4. Usage of export default
5. Accessibility
6. Construction of Component Props Types
7. About CSS Styling
8. Form Validation
9. Code Repository Management
10. Conclusion

Do We Need Next.js?

The dify/web is built with Next.js. I observed that apparently, Dify does not need SSR capabilities, and the use of many 'use client' suggests that most of the project is CSR.

I think using Vite might offer a better experience. If File-Based Routes are needed, consider using TanStack Router or Remix 🤔 Although, there isn’t a big issue with using Next.js as it also provides many optimizations at a meta-framework level.

About Data Fetching

I saw code in the project using useEffect to fetch data, which is not generally recommended in React. Here's a blog post explaining why, https://tkdodo.eu/blog/why-you-want-react-query

Also, the project dependencies include both ahook and swr. ahook's useRequest and swr, TanStack Query offer similar capabilities. There are also portions of the code where swr is used.

In terms of data fetching, I think it would be better to unify this aspect to provide a unified path for future maintenance and centralized management.

Usage of export default

This may be more of a personal preference 🤣

Where not necessary, I suggest using export, which seems to work better with reference finding in VS Code (personally speaking).

export default is friendlier for dynamic imports, as it doesn’t require writing lengthy code.

example:

// export
export function CreateWorkspaceModal(){}
// usage
const CreateWorkspaceModal = lazy(() =>
  import('../components/affine/create-workspace-modal').then(module => ({
    default: module.CreateWorkspaceModal,
  }))
);

// export default
export default function CreateWorkspaceModal(){}
// usage
const CreateWorkspaceModal = lazy(
  () => import('../components/affine/create-workspace-modal')
);

Accessibility

I've briefly looked into Accessibility, and it seems to be lacking.

It is evident in the construction of basic components, which do not follow Accessibility standards.

Construction of Component Props Types

Currently, it is like this:

dify/web/app/components/base/button/index.tsx

Lines 25 to 35 in aefe0cb

	switch (type) {
	case 'primary':
	style = (disabled || loading) ? 'btn-primary-disabled' : 'btn-primary'
	break
	case 'warning':
	style = (disabled || loading) ? 'btn-warning-disabled' : 'btn-warning'
	break
	default:
	style = disabled ? 'btn-default-disabled' : 'btn-default'
	break
	}

I suggest this might be slightly better 🫣:

https://github.com/shadcn-ui/ui/blob/816b654f07b77c9c4c160ed42f0bb104592e3484/apps/www/registry/default/ui/button.tsx#L7-L34

About CSS Styling

The project uses almost all styling methods available in Next.js 🤣. Solely using Tailwind CSS indeed makes some styles hard to write, but I think pairing it with either CSS Modules or Sass would be better. Introducing too many things increases the complexity.

• CSS Modules
• Tailwind CSS
• Sass

Form Validation

The current implementation uses hand-written regex 🤣.

It might be easier to incorporate a form library like React Hook Form.

example: https://ui.shadcn.com/docs/components/form#example

Code Repository Management

As a frontend developer, I generally pay less attention to the backend. Currently, Dify's frontend and backend code are stored together. Recently, I encountered a frontend error; my commits were behind the remote repository. I was able to replicate the issue locally, but, miraculously, the error disappeared after updating my code. When I wanted to check the commit history to find the cause of the fix, I found that most of the commits were related to the backend, with very few frontend commits.

What I want to suggest is the possibility of separating the frontend and backend code, allowing each to operate within their respective domains. This would also narrow down the scope when troubleshooting issues.
These are just some humble opinions on the Dify frontend code~

Conclusion

Actually, these are not major issues. In today’s rapidly evolving AI era, it’s crucial to act quickly to gain a headstart. However, if some uniform requirements could be established, forming a set of standards, it would undoubtedly be clearer for the contributors who join later. They could learn about some of the best practices in frontend development by reading Dify's code.

Let's Do IT Better! 🚀

[guchenhe]

hi @TinsFox 👋,

thanks for the long post and all the feedback! I'll first get to your more meta questions:

• Next.js: This was decided very early on, and I think it made sense back then as a powerful, general-purpose framework that's backed by a large community. we've grown and changed quite a lot since the very beginning, and you are right to point out that we've not been using SSR. in short, it isn't really a necessity at this point. From an open source perspective though, next.js has very wide adoption, whereas an alternative framework might pose a learning curve for more contributors. then there's also the cost to actually make the switch... due to these, the overhead might not justify a framework change at the moment.
• Monorepo: Keeping our code as one repo currently helps us sync dev and release cycles a lot easier, since all of our major feature releases require coordinated changes to both the front and backend. and a benefit to having unified commit histories is that it helps us track these changes much better.

a lot of your other points are also valid, i've shared your feedback with team. I do agree that we've made tradeoffs in standardizing our code due to the necessity to move fast at this stage. will be sharing more updates as we hopefully get to improve the code base for new contributors to onboard easily.

[TinsFox]

I see, thanks for sharing the details.

[TinsFox]

I created a PR for form validation improvements here is the link #4154