Hybrid design implementation. Merge or make from scratch?

I have been fighting a lot with the styling implementations of Ionic. When I use components like ion-button to display a button, it is easy to style it to fit at custom design by using various variables like --color and --background-hover. The problem is when I try to wrap it in other components. When putting it inside a toolbar and ion-buttons, Ionic adds a lot of other classes like .sc-ion-buttons-md-s ion-button:not(.button-round) that override the variables I have set on the ion-button-element in my styles.

But at the toolbars in question, I want the buttons to look just like other buttons. The only way I have found to override this, is to add the variables directly on the native-part, som either ion-button::part(native) { *** } or repeating the style rules on ion-buttons ion-button::part(native). But some styles override this as well. Like some times the button color is overridden by a style set on the .button-native setting color: inherit.

The above details was just one example. I experience quite a bit of these kinds of issues. It seems it is a bit hard to combine custom styles with the default ones. It might be reasons why styles are overridden in certain constexts (like buttons inside a toolbar) but it makes it hard to customize the design to the needs for the application.

I have actually considered dropping ion-components and building all components from scratch. This is for the beginning of an app that will grow a lot over time, so the architectural choices here matters a lot, and getting things up and running quickly (which ionic seems fantastic at) is a bit less important than practical maintainability and development speed over the time of the application lifespan.

So, anyone else here who has considered similar issues? What have you decided to do in cases like this? Thank you!

1 Like

I got your point , I have also facing similar issues while doing custom things on ionic elements , in that case i prefer the my way of doing things like you mentioned your own component from scratch , which gives you more control overtime , it’s a one time investment benefit in long run. PS: if you don’t have time constraints

When making custom code from scratch instead of using ion*-code, do you know how that affects the native builds? Like if I make a date picker instead of using the IonDatetime react component in my application, does that lead to code running in a web view instead of using native pickers on platforms like iOS and Android?

Makes zero difference. The stock Ionic datetime picker is just this dude.

i see you still struggling with the shadow classes @henit :slight_smile:

Yes I am :slight_smile:
Making a design implementation depends a lot on the way Ionic combines inerhited styles. And by my experience so far, it requires a bit too much tweaking to get things working, and it might not be worth it compared to making it from scratch in cases like this, where it is supposed to grow into a larger application over time.

I might have misunderstood, but I thought standard features (like overlay dialogs, datepickers, menus and so on) used native features on platforms like iOS and Android? Is everything just displayed within a web view and emulates the look of the native components?

Generally speaking, no. That stuff lives in webviews.

Again, basically yes, but with the caveat that Capacitor gives you a bridge to communicate with plugins that are written in Java / Swift to access functionality that is either impossible or inconvenient to do from within a webview. Push notifications, NFC, mobile keyboard - that sort of thing. More comprehensive list here.

1 Like