You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In addition, I think it would be helpful for future development to provide our own card component, even if that's just a thin wrapper around the Bootstrap card. This will act as a stable interface that we can reimplement if we choose to drop Bootstrap in the future and, say, adopt Vuetify or some other Material Design framework.
Towards that end, I'd like to take steps towards encapsulating all Bootstrap styles in Vue components, which can become part of the component library I'm building up to support Field Modules. That way, the main application code should not include any Bootstrap classes in its markup; those classes would only be applied within the components of the component library, and so would be essentially hidden to anyone using that library.
For example, we're already doing something similar with our farm-drawer-list component:
Now instead of exposing Bootstrap's API, we've exposed our own API, over which we have full control. Of course, there are trade-offs to that, namely that we must maintain and document* that API, but I think that is worth the ability to change the underlying implementation whenever we want, while also being able to restrict/expand what's available in Bootsrap.
Bumping this up to 1.1.0 because we should have a stable, component-based API for styling Field Modules before they start to proliferate. In other words, we don't want to create a bunch of Field Modules that use the Bootstrap classes directly, only to have to convert them all once we've encapsulated them in Vue components.
Expanding on #263 (comment):
Towards that end, I'd like to take steps towards encapsulating all Bootstrap styles in Vue components, which can become part of the component library I'm building up to support Field Modules. That way, the main application code should not include any Bootstrap classes in its markup; those classes would only be applied within the components of the component library, and so would be essentially hidden to anyone using that library.
For example, we're already doing something similar with our
farm-drawer-list
component:https://github.com/farmOS/farmOS-client/blob/909befe86f2727f65ec2daa2fb7fd8e7580fe7fb/src/components/FarmDrawerList.vue#L2-L4
and our
farm-drawer-list-item
component:https://github.com/farmOS/farmOS-client/blob/909befe86f2727f65ec2daa2fb7fd8e7580fe7fb/src/components/FarmDrawerListItem.vue#L2-L6
Those two components combined lead to application code that is decoupled from the underlying CSS classes:
https://github.com/farmOS/farmOS-client/blob/909befe86f2727f65ec2daa2fb7fd8e7580fe7fb/src/core/App.vue#L25-L46
Now instead of exposing Bootstrap's API, we've exposed our own API, over which we have full control. Of course, there are trade-offs to that, namely that we must maintain and document* that API, but I think that is worth the ability to change the underlying implementation whenever we want, while also being able to restrict/expand what's available in Bootsrap.
* Documentation can also be aided with libraries like Storybook: https://storybook.js.org/.
The text was updated successfully, but these errors were encountered: