-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bootstrap4 #437
base: master
Are you sure you want to change the base?
Bootstrap4 #437
Conversation
lhfi
commented
Sep 30, 2021
Q | A |
---|---|
Is bugfix? | no |
New feature? | yes |
Breaks BC? | no |
Tests pass? | |
Fixed issues |
Requires Kartik Gridview Requires lhfi/yii2-selectize-widget
Thank you!! I've created a |
@lhfi can you please re-direct this PR from master to bootstrap4 branch? Hopefully then it can be easily merged and others can start using and contributing additionally to the work you have done |
use lhfi repository for bootstrap4 version of selectize widget
Selectize widget depends on lhfi dev-bootstrap4 branch
fix dependency of yii2-bootstrap4 version to ^2.0
When will this update appear at least in dev? Bootstrap5 is already in use) |
Hi guys, |
I'm already using bootstrap 5 in yii2, had to redo all the view this extensions |
I created a separate repo that has the bootstrap4 views here Having views decoupled entirely from the base module is also one of the ideas discussed earlier here in #289 Similarly bs5 views could be created and linked as a separate repo. Care to share some code @scorpsan as a bs5 repo similarly to the bs4? |
While splitting out the view probably makes the most sense... I don't think it is the right way. The lowest hanging fruit is to support Bootstrap5 since 3 is EOL and 4 will be EOLd 01 Jan 2023. I'll submit an updated PR which includes Bootstrap5 that should probably be tagged as If you think the tag of 1.6 is sufficient until views can be separated that is fine as well. |
What other option do you suggest? |
I would completely remove the bootstrap dependency from the module instead of locking to another views implementation. What if I want to use [your-preferred-ui-framework-here-not-being-bs] instead? The Yii3 example web app also skips ANY frontend framework https://github.com/yiisoft/app to allow users to choose the front end look. I would go from removing the BS related dependencies all together and have a default views repo (eg bs-5) that could be included as a suggested dependency. This way an app could easily be kept as bs3 or bs4 (or whatever) without getting any dependency conflicts. It is far more flexible, will allow users to be up to date with the usuario package without being forced to upgrade their application looks to any fixed frontend framework. I do think this makes a lot of sense and is the right way to be up to date with views in the future. I would happily make use of any bs-5 based views repository if you would release it separately @cgsmith :) |
@TonisOrmisson I agree with you 100%. I'll be making a repo with BS5 views and also updating the current repo to use the BS5 views. We are a little behind doing that with this repo which is why I suggest releasing a 1.6.x with BS5 views built in. When views are removed, as you have discussed, then a future release should break that BC. It would make sense to me to keep the scope of work smaller and iterate through a release cycle. |
Depends on from what end you look at it :) If you switch from bs3 to bs5 in the core, then the applications using bs3 (most of them out there) would need to either migrate their whole applications to bs5 or override the bs5 views back to a bs3 version not to break their applications with the upgrade. If you introduce a bs5 views repository, all current apps would be safe and only apps that are ready to migrate can override the views to the new bs5 version. The work amount of actually re-doing the views from bs3 to bs5 is the same either inside the core module or in a separate repo. Having it in a separate repo seems to be a less breaking way of doing it. By making an bs5 views repo, you do not need to have an update on the core package itself at all, no version upgrade needed etc. If it works good and people migrate to the separate repo, we can do a new (major?) release replacing the core bs3 views with bs5 views while having the dependency it as a suggested package. At the same time making a backup of the bs3 views as a backup separate repo for apps that need the bs3 version. |
Here is a repo with the current bs3 views for the scenario if the bs3 views would be not included in this repo any more. |