New to Fluent UI React.
I have been tinkering around with the framework and read through all of its documentation that I can find. My understanding is that CSS-in-JS approach is encouraged when it comes to component styling. I see there are two ways to do so–via the styles prop and via the use of the mergeStyleSets utilities function + the className prop. Here is a codepen to illustrate what I mean here.
My question is, do they serve different use cases or are they pretty much the same? How do I decide which one to use? Thanks.
I've tried both and am leaning more toward mergeStyleSets because it gives me one way to predictably target everything and I don't have to learn the "magic class names" buried deep within each component and what it does or does not affect. Having said that, for certain key components, like DataGrid, there's a lot of styling involved and the classes exposed are not too difficult to learn and are helpful for getting the best out of those components.
This is particularly the case when you have to do selectors for things like "hover" or "active" or "before/after". Trying to get that working via magic class names exposed by "styles" was much more confusing for me than using the "mergeStyles" approach on the raw HTML directly.
So for me, I've been cherry picking from the framework, using it for color themes, elevation, and highly complicated components like DataGrid, but not for things like Stack or Stack Item.
Related
Kind of a beginner's question - I try to get a deeper understanding of the above components, and about there differences. These is how far I got, maybe it can illustrate my confusion a bit:
ThemeProvider: From my tests, it provides a Palette with my style settings for MUI components. N/c where it gets accessed, but I figure MUI components to that implicitely at some point. At least the according Theme is made available in all kind of hooks as well as in createTheme in #mui/material/styles, so I figure this is the one component I understand the most.
StyledEngineProvider: According the documentation, it is there for "generating CSS styles for MUI components". What exactly is the difference to ThemeProvider? I've noticed that it must be a child of the ThemeProvider component and not the otherway around, or my Palette won't apply. Most guides call it with the property injectFirst - I figure this way the css data will be put at the start of html's head. So is it there to inject css data into the html? I seem to need it when using tss-react though.
CacheProvider from #emotion/react: Not sure what's actually cached and I didn't find any example where it's accessed/used in custom code. The documentation here is rather sparse as well, but it tells me to replace <StyledEngineProvider injectFirst> with it. So it seems to expect injectFirst to be set whatsoever, and it seems to work more or less as drop-in replacement of StyledEngineProvider. I noticed it has a property prepend which I suspect to have a similar effect as injectFirst. Then, there is a key property - a "prefix" for the css classes, as the documenation says. I figure it's there to allow multiple caches in multiple namespaces, but I wouldn't even know how to specify the key/namespace to be used.
If anybody could shed some light on (some) of these questions, I'm grateful!
in our new project we've transited to mui 5. I found that we are using sx prop much for custom layouts and components. there are many examples of such usage in documentation of mui itself. it looks a bit hard coded for me:
it's very similar to usage of style property for inline styling. how reuse of styles should be organized here?
it's not comfortable for debugging too since sx props has no name and it's hard to identify what component styles come from. is there any way to have sx prop named?
Will appreciate if somebody will share best practices how to organize style with mui 5 in proper way.
cheers.
Pretty much the title, im trying to make a widget that contains some data and linecharts, i know this glance stuff is pretty new, so im not sure if its possible to do this.
Glance is limited by the RemoteViews capabilities, thus you cannot create custom views. Instead you would need to render a bitmap with your linechart and use it in an Image composable.
I believe some graph libraries out there allow to export a chart to a drawable/bitmap
Beginning to build a new UI library using the atomic design methodology we quickly ran into a problem when trying to categorise the smallest UI building blocks as atoms. An example here might be a React component that might be say, <SVGComponent />. Initially classified as an atom - it quickly became apparent that it probably wasn't. In terms of atomic design it wouldn't fit the vocabulary of being an atom - it is an implementation detail. So an <Icon /> component might fit the design classification of atom and the implementation of that component might be composed of an <SVGComponent />. There are other examples of such components eg <Font/>.
Is there a common parlance for describing and classifying such components alongside an atomic ui library and where a dependency exists? Any thoughts generally on this?
Thanks
I'm not an expert in concepts of AD, but referring to the definition:
Atoms are the smallest possible components, such as buttons, titles,
inputs or event color pallets, animations, and fonts. They can be
applied on any context, globally or within other components and
templates, besides having many states, such as this example of button:
disabled, hover, different sizes, etc.
So, if I understood the purpose of <SVGComponent /> right, I don't quite agree that it doesn't fit the vocabulary of being an atom. Comparing it with the <Button /> component (which is an atom), it can freely receive props like 'width', 'height', 'viewBox', etc.
As for the <Icon /> component, it's not necessary to compose <SVGComponent /> inside of it. You could try to pass something like 'src' prop to Icon, which can be one of various types (img src, raw svg code, etc).
Just my two cents. Hope it helps.
I'm building a simple text editor that relies on Draft.js for decorating the text (mainly highlighting). I really like how simple it is to build a reliable input that has custom syntax highlighting.
However, I do not like the fact that I have to expose the entire editor state to do this. I'd prefer to have an editor that has just a value property that takes a string and passes a string trough the onChange prop.
This seems a reasonable thing to be able to do, yet I'm dumbfounded by how hard it is to transfer selection state.
Because of how draft.js is implemented, I find this hard to do. I need to create a new editorState based on the value prop every time it changes, which is doable, But it is hard to transfer selectionState between the old editorState and the new one because the selectionState relies on opaque identifiers that are unique to each state.
Has anyone tried to accomplish this? Is draft.js overkill for this an should I use a simpler solution that also works? I'm only using the decorators so I guess it would not be super-hard to just rebuild that part.