Very often I'm seeing that third party react native components don't provide granular access to changing their styles. On web we can target and style different parts based on their CSS classes. If a react native component does not provide enough props for changing styles, how to go about changing its styles?
It's common to me to read the third party lib code on github and then write a component that do the same thing but with my styles, Generally speaking it's not much complex depending on the library of course, for small libs it works very well.
It's only worth when the lib doesn't provide a way of overriding styles as you have pointed.
You also can see the style implementation of lib's main component and override it's styles, using JSS or styled-components lib.
Related
I have two SPA on vue, on same deployment area:
Uses Vuetify (www.someserver.com/portal_1/)
Uses Bootstrap-vue (www.someserver.com/portal_2/)
Now I need to make some portal area with components from both SPA. Is there any methodology to deal with it?
I try to create app with vuetify and bootsrtap-vue, but stuck with many sass errors...
I have struggled with the same issue regarding Vuetify styles. I needed to have a second Vue app embedded inside my Vuetify app but the Vuetify styles kept leaking inside the child Vue app, and the global styling coming from child app also broke Vuetify defaults.
I have done a long research and concluded that the options are:
-Rewrite the child app using BEM approach (Still Vuetify would leak with selectors like p, head, body etc.)
-Disable Vuetify's CSS reset file, remove globals and disable theming via hacky approaches.
-Use an iFrame container or web components approach on the second app to isolate it from the other.
Messing with Vuetify library didn't sound too great, because it will be too chaotic to deal with problems later on. We decided to completely isolate two Vue instances via an iFrame in the end, and I'd recommend the same thing if you REALLY need to use both bootstrap-vue and Vuetify, because they both have global CSS selector modifiers and stuff that will just create a huge mess.
I had my team do further research on iframes and how to consistently pass data between an iframe and parent app, here are the two options that you may consider:
vuex-iframe-sync (a lightweight option but I couldn't get it to work properly)
https://github.com/L-Chris/vuex-iframe-sync
Zoid (a library maintained by payPal, very solid approach but tricky to set up with Vue)
https://github.com/krakenjs/zoid
Further info on how to set up zoid with Vue:
https://github.com/krakenjs/zoid/issues/296
PostRobot (Haven't tried this one but also a solid option, probably much easier than zoid)
https://github.com/krakenjs/post-robot
Good luck, and please let me know if you find any other approach that works!
In case of using UI frameworks (like Bootstrap-Vue, ElementUI or Vuetify, etc.) in our Vuejs application, it's possible to import entire UI framework components & stylesheets from node_modeules in the App.vue(or in the application entry point), or importing a particular ui component in particular Vue file/Component as needed.
The demonstration of these two approches looks like:
For scenerio 1
in App.vue
import BootstrapVue from 'bootstrap-vue'
For scenerio 2
in any particular .vue file
import {BContainer} from 'bootstrap-vue'
So,In case of the first option, does it make the application slower or less performing as all components from UI framework is loading for each route change? Also, its's loading some components that are not needed.
On the other hand, it's quite inconvenient to import each ui component in every .vue file.
So what is the best practice for small or large scale web applications?
Does the practice is same for other JS frameworks/Libraries link React or Angular?
Thanks in advance.
Scenario 1 – register all components globally
All components from the library will be available to use everywhere.
If you change or update the library and some of the component names have changed, you won't get any errors at build time.
Scenario 2 – pick-and-choose specific components locally
Gets annoying to have to import each component when you want to use it.
Only components that are actually used (imported) will be included in the bundle (if using webpack or something similar). Results in a smaller bundle size.
It is clearer to look at the template and know where each component comes from. If you have lots of globally-defined components then there is no clear link between a component and where it came from.
If you change or update the library and some of the component names have changed, you will get build errors due to missing modules.
So,In case of the first option, does it make the application slower or less performing as all components from UI framework is loading for each route change? Also, its's loading some components that are not needed.
It does make a difference when you are importing the entire package globally. Also it won't reload the package for every route change as you have the import inside App.vue. It will be done once when your app is loaded for the first time.
I found this article very helpful on how to optimize loading 3rd party components into vue app.
On the other hand, it's quite inconvenient to import each ui component in every .vue file.
End of the day it all comes to how much of tradeoff your development team is willing to make between optimizing the app and adding multiple lines of import code into individual components.
Is there a best practice or list of pros and cons in deciding when to use a styled component instead of the css prop?
I generally prefer styledComponent but, there are certain edge cases like styling your <Link /> for react-router where you have to provide a compiled style to className prop.
There is no harm in using CSS props but, there is a chance of accidentally overriding your styles, plus it makes your JSX messier. But if you know what you are doing and you are heavily using composition then IMO it is quite a powerful feature.
It is much easier to understand and manage the styled-components, like when using themes you can encapsulate the whole styling logic away from your JSX. +1 to styled-components for lego based design.
I think it is safe to say, you can use styled-components and CSS together but adopting either one for the majority of your components.
I absolutely love how you can override your base components using emotion's composition(which saves us from passing weird props and helps to keep the props cleaner) but at the same time you should not abuse it as from personal experience it's tempting to just use CSS composition where you should be using props like isBold fontSize: "sm" ...
I've started a Microsoft fabric-react, using the Typescript-React-Started provided by Microsoft here.
Although the excellent Fabric-react documentation available here, i wasn't able to find any documentation on how to style the fabric-react components.
For example, the Microsoft documentation for the Commandbar component is available here.
The default theme renders the Commandbar background with a gray color, with blue command buttons.
From what i could understand, Microsoft provides a Themes/Styling system.
Unfortunately, i wasn't able to find any start-to-end example, on how to change the default theme, or create a custom theme.
So, my questions are:
How can i change the default theme, and apply a specific theme on a fabric-react component?
How can i create a custom theme?
Thanks for using Office UI Fabric React! Have you had a chance to read these wiki pages regarding styling and applying a theme to components?
https://github.com/OfficeDev/office-ui-fabric-react/wiki/Component-Styling
https://github.com/OfficeDev/office-ui-fabric-react/wiki/Theming
https://developer.microsoft.com/en-us/fabric#/components/themes
You can also generate your theme via https://developer.microsoft.com/en-us/fabric#/styles/themegenerator then apply it using the method described in the page(s) above.
This is a copy of Microsoft response on Github, so the merit is not mine :)
Current
Use loadTheme to provide component wide colors and fonts.
Use styles prop for components for one-off tweaks.
If you'd like to provide a standard styles override for a specific component type, you can use Customizer to provide scopedSettings to pipe in standard overrides. (Not this is experimental and will likely change.)
Legacy className / global css support still works, which is to use className to provide your own class overrides, and to reference global class names as needed. Though this is an option, this is is not recommended, as it's very fragile and suffers from numerous issues (selector specificity, no build time validation, easy to break, etc.) We're considering removing the global class names completely in a future major release.
In progress
Our goal is to move all customization into the theme; this lets you rev your design over time. We are tracking a bunch of work here: https://github.com/OfficeDev/office-ui-fabric-react/projects/26
The problems we've recognized
Customizer for providing contextual overrides is too generalized, and doesn't allow us to have theme-specific logic like caching themes.
ITheme should be expanded to allow you to pipe in component-specific overrides, in addition to other site-wide settings like sizing, shadowing, and animations.
Passing in styles is not a good contract; you need to know which component parts to target for the styling (sometimes multiple parts) and sometimes which selectors to override (do i use a pseudo element here? is my selector not specific enough?)
No support for color schemes (think the "dark header", where the Toggle should look different than in the "light content area".
Solutions to shortcomings
Expose a dedicated ThemeProvider component. We will still have loadTheme for providing the default theme, while ThemeProvider can switch out scheme, or even theme in a box.
Add support for color schemes.
Introduce style variables, which abstract the common knobs from full styles definitions. This lets you not worry about parts or selectors, and simply focus abstractly on what the component should look like. We have this experimentally in our Button and Toggle refactors in experiments.
I want to know that whether the <List> component being provided by native-base
styling library can be an alternative for <ListView> component.
I know that the the traditional listview by react-native is performance efficient
so is the List component of native base also performance efficient.
Check NativeBase Docs https://docs.nativebase.io/Components.html#list-def-headref
It says, List is deprecated
NativeBases List component is actually just a wrapper over React Native's ListView with some extra goodies included, so efficiency in terms of cell reuse, etc should be good.
See the source for List.