Replies: 2 comments 1 reply
-
hi @TinsFox 👋, thanks for the long post and all the feedback! I'll first get to your more meta questions:
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. |
Beta Was this translation helpful? Give feedback.
1 reply
-
I created a PR for form validation improvements here is the link #4154 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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
export default
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-queryAlso, 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:
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
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.
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! 🚀
Beta Was this translation helpful? Give feedback.
All reactions