Closed Tanvir-rahman closed 4 years ago
This pull request is being automatically deployed with Vercel (learn more). To see the status of your deployment, click below or on the icon next to each commit.
🔍 Inspect: https://vercel.com/hikaya/vue-ui-components/615acwyy3 ✅ Preview: https://vue-ui-components-git-ui-80.hikaya.now.sh
Hey @Tanvir-rahman I don't think we agreed to using Tailwind. We were only to use it as reference when customizing element UI. I think adding another library will make it more difficult to maintain this project especially for new comers.
Hey @Tanvir-rahman I don't think we agree to using Tailwind. We were only to use it as reference when customizing element UI. I think adding another library will make it more difficult to maintain this project especially for new comers.
Ok. At First, I was asked to add tailwind in the project. That's why added it. From activity meeting, issue assigned and was told. That's not the issue. We can just close the issue 😄
Secondly, at first it might look difficult like everything else in life but day by day it will make developer's life too easy. It's just utility library used only for css not another framework for component.
Secondly I can give some example of it's usecase. Like when you will develop a dashboard management system, suppose you used 10px spacing between every two component in 20 ~ 40 pages. And in these pages there are suppose 5 pairs of input box. Now later if you want to change the spacing, how many places do you need to modify? Suppose one developer wrote 10 px at one place another developer wrote 15px. How do you identify this?
To solve this, suppose you will make common scss class to manage space between two components. How many classes can we introduce then for every scenerio? Tailwind handles all these from a single config file....
I think for long run we need to think about these kind of decision. And if you say about difficulty i really think people who had self learned vue.js ecosystem and CSS, can also adopt this easily.
Hey @Tanvir-rahman I don't think we agree to using Tailwind. We were only to use it as reference when customizing element UI. I think adding another library will make it more difficult to maintain this project especially for new comers.
Ok. At First, I was asked to add tailwind in the project. That's why added it. From activity meeting, issue assigned and was told. That's not the issue. We can just close the issue smile
Secondly, at first it might look difficult like everything else in life but day by day it will make developer's life too easy. It's just utility library used only for css not another framework for component.
Secondly I can give some example of it's usecase. Like when you will develop a dashboard management system, suppose you used 10px spacing between every two component in 20 ~ 40 pages. And in these pages there are suppose 5 pairs of input box. Now later if you want to change the spacing, how many places do you need to modify? Suppose one developer wrote 10 px at one place another developer wrote 15px. How do you identify this?
To solve this, suppose you will make common scss class to manage space between two components. How many classes can we introduce then for every scenerio? Tailwind handles all these from a single config file....
I think for long run we need to think about these kind of decision. And if you say about difficulty i really think people who had self learned vue.js ecosystem and CSS, can also adopt this easily.
I think we can configure grid space or component spacing in element UI already by just overriding specific variables. I noticed that tailwind uses class based styling, like bootstrap, meaning classes will have added to each component that needs to be affected. If this is the case, it would be better to define our own variables in element and use them or use bootstrap instead since more people are familiar with bootstrap than tailwind.
Hey @Tanvir-rahman I don't think we agree to using Tailwind. We were only to use it as reference when customizing element UI. I think adding another library will make it more difficult to maintain this project especially for new comers.
Ok. At First, I was asked to add tailwind in the project. That's why added it. From activity meeting, issue assigned and was told. That's not the issue. We can just close the issue smile Secondly, at first it might look difficult like everything else in life but day by day it will make developer's life too easy. It's just utility library used only for css not another framework for component. Secondly I can give some example of it's usecase. Like when you will develop a dashboard management system, suppose you used 10px spacing between every two component in 20 ~ 40 pages. And in these pages there are suppose 5 pairs of input box. Now later if you want to change the spacing, how many places do you need to modify? Suppose one developer wrote 10 px at one place another developer wrote 15px. How do you identify this? To solve this, suppose you will make common scss class to manage space between two components. How many classes can we introduce then for every scenerio? Tailwind handles all these from a single config file.... I think for long run we need to think about these kind of decision. And if you say about difficulty i really think people who had self learned vue.js ecosystem and CSS, can also adopt this easily.
I think we can configure grid space or component spacing in element UI already by just overriding specific variables. I noticed that tailwind uses class based styling, like bootstrap, meaning classes will have added to each component that needs to be affected. If this is the case, it would be better to define our own variables in element and use them or use bootstrap instead since more people are familiar with bootstrap than tailwind.
I appreciate your concern. But Tailwind and Bootstrap is two different things.
Tailwind is different from frameworks like Bootstrap, Foundation, or Bulma in that it's not a UI kit. It doesn't have a default theme, and there are no build-in UI components. It comes with a menu of predesigned widgets to build your site with, but doesn't impose design decisions that are difficult to undo.
Also i can add tailwind is just more defined way to write your css. It just prohibits to write spaghetti code and makes product more manageable..... Ok i already explained in my way. And what i thought. Decision is upto teams or May be in future when we will feel much needed.... 😄
Hey @Tanvir-rahman I don't think we agree to using Tailwind. We were only to use it as reference when customizing element UI. I think adding another library will make it more difficult to maintain this project especially for new comers.
Ok. At First, I was asked to add tailwind in the project. That's why added it. From activity meeting, issue assigned and was told. That's not the issue. We can just close the issue 😄
Secondly, at first it might look difficult like everything else in life but day by day it will make developer's life too easy. It's just utility library used only for css not another framework for component.
Secondly I can give some example of it's usecase. Like when you will develop a dashboard management system, suppose you used 10px spacing between every two component in 20 ~ 40 pages. And in these pages there are suppose 5 pairs of input box. Now later if you want to change the spacing, how many places do you need to modify? Suppose one developer wrote 10 px at one place another developer wrote 15px. How do you identify this?
To solve this, suppose you will make common scss class to manage space between two components. How many classes can we introduce then for every scenerio? Tailwind handles all these from a single config file....
I think for long run we need to think about these kind of decision. And if you say about difficulty i really think people who had self learned vue.js ecosystem and CSS, can also adopt this easily.
@Tanvir-rahman Sorry about the confusion. I was hoping we explore Tailwind in more detail but should have made more clear we were not ready to move forward. I think the team needed more understanding so your explanation for the benefits is good and we can consider for the future. Also now that we have the global SCSS files we can use the standard variables and CSS classes that will help to keep the components consistent. Apologies again about the confusion 🙏
What is the Purpose?
A utility framework added named 'Tailwind Css' with current component system.
What was the approach?
Configurations added
Are there any concerns to addressed further before or after merging this PR?
No. Just use class from tailwind. It will work
Mentions?
@michaelbukachi
Issue(s) affected?
Nope
** For further optimization and modification, we need to adjust configuration according to our need / theme.Will be mostly useful in Dashboard and in our full custom component..