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.
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!
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.
I have an InfiniteContainer list where each element is a relatively complex container with several different buttons with each their action. Since it's a scrollable list, I use LongPointerPress to activate drag and drop like Shai recommended in another post. To do this I need to set a lead component to handle this. However, when I set it, none of the other buttons get their individual events. I thought I could overwrite the getLeadComponent() of the buttons to have it return null, to ensure those buttons handle their own events, but it's private and haven't been able to think of any other solution for now.
Is there a recommended approach for handling this?
NB. I've been spending a LOT of time piecing together partial advice from different posts, and using trial and error to get this UI to work. It would be useful if the CN1 documentation could contain more explicit advice on the approaches that work for such 'real life' complex UI which combine eg lists, drag&drop, multiple buttons, long press for additional actions, Swipable containers, ... It shouldn't feel like constant hacking ;-)
You can setLeadComponent(null) when you are done with the lead component functionality to "undo" the lead component effect. The lead component behavior is an "all or nothing" approach.
If this doesn't work for you you can override the low level events in the Form and implement the functionality there. You can block components from getting events by not calling super.pointer* methods in Form and thus allow any sort of effect.
I wonder whether I should choose an Ext.Panel with an hbox layout or an Ext.Toolbar in order to put some buttons below a comment input field. Both are suitable for holding a set of controls.
It depends on the required functionality- using a hbox leads to further nesting within your view, so a more complex dom (which typically should be avoided), whereas a toolbar can be applied directly to the parent component. Though both may be suitable for holding a set of controls, toolbars are specifically designed to do so, as such they are a more complex object- again, if you require the functionality they provide (styling, methods etc) then using one should be the choice. Its kind of hard to say based on the limited detail provided
In case a screen of a WPF application contains lots of primitive controls, its rendering becomes sluggish. What are the recommended ways to improve the responsiveness of a WPF application in such a case, apart from adding fewer controls and using more powerful videocard?
Is there a way to somehow use offscreen buffering or something like that?
Our team was faced with problems of rendering performance. In our case we have about 400 transport units and we should render chart of every unit with a lot of details (text labels, special marks, different geometries etc.).
In first our implementations we splitted each chart into primitives and composed whole unit's chart via Binding. It was very sad expirience. UI reaction was extremely slow.
So we decided to create one UI element per each unit, and render chart with DrawingContext. Although this was much better in performance aspect, we spent about one month improving rendering.
Some advices:
Cache everything. Brushes, Colors, Geometries, Formatted Texts, Glyphs. (For example we have two classes: RenderTools and TextCache. Rendering process of each unit addresses to shared instance of both classes. So if two charts have the same text, its preparation is executed just once.)
Freeze Freezable, if you are planning to use it for a long time. Especially geometries. Complex unfreezed geometries execute HitTest extremely slow.
Choose the fastest ways of rendering of each primitive. For example, there is about 6 ways of text rendering, but the fastest is DrawingContext.DrawGlyphs.
Use profiler to discover hot spots. For example, in our project we had geometries cache and rendered appropriate of them on demand. It seemed to be, that no improvements are possible. But one day we thought what if we will render geometries one time and cache ready visuals? In our case such approach happened acceptable. Our unit's chart has just several states. When data of chart is changed, we rebuild DrawingVisual for each state and put them into cache.
Of course, this way needs some investments, it's dull and boring work, but result is awesome.
By the way: when we turned on WPF caching option (you could find link in answers), our app hung up.
I've had the same perf issue with a heavily customized datagrid since one year, and My conclusion is:
there is basically nothing you can do
on your side (without affecting your
app, i.e.: having fewer controls or
using only default styles)
The link mentioned by Jens is great but useless in your case.
The "Optimizing WPF Application Performance" link provided by NVM is almost equally useless in my experience: it just appeals to common sense and I am confident you won't learn anything extraordinary either reading. Except one thing maybe: I must say this link taught me to put as much as I can in my app's resources. Because WPF does not reinstanciate anything you put in resource, it simply reuses the same resource over and over. So put as much as you can in there (styles, brushes, templates, fonts...)
all in all, there is simply no way to make things go faster in WPF just by checking an option or turning off an other. You can just pray MS rework their rendering layer in the near future to optimize it and in the meantime, try to reduce your need for effects, customized controls and so on...
Have a look at the new (.NET 4.0) caching option. (See here.)
I have met a similar problem and want to share my thoughts and founds. The original problem is caused by a virtualized list box that displays about 25 complex controls (a grid with a text block and a few buttons inside displaying some paths )
To research the issue I used the VisualStudio Application Timeline that allows to how much time it takes to render each control and PerfView to find out what actually WPF is doing to render each control.
By default it took about 12ms to render each item. It is rather long if you need to update the list dynamically.
It is difficult to use PerfView to analyse what heppens inside since WPF renders item in the parent-child hierarchy, but I got the common understanding about internall processes.
WPF does following to render each item in the list:
Parse template using XAML reader. As far as I can see the XAML parsing is the biggest issue.
Apply styles
Apply bindings
It does not take a lot of time to apply styles and bindings.
I did following to improve performance:
Each button has its own template and it takes a lot of time to render it. I replaced Buttons with Borders. It takes about 4-5ms to render each item after that.
Move all element settings to styles. About 3ms.
Create a custom item control with a single grid in the template. I create all child elements in code and apply styles using TryFindResources method. About 2ms in the result.
After all these changes, performance looks fine but still most time is spent on loding the ListControl.Item template and the custom control template.
4. The last step: replace a ListControl with Canvas and Scrollbar controls. Now all items are created at runtime and position is calculated manually using the MeasureOverride and ArrangeOverride methods. Now it takes <1ms to render each item from which 0.5ms is spent on TextBlock rendering.
I still use styles and bindings since they do not affect performance a lot when data is changed. You can imagine that this is not a WPF solution. But I fave a few similar lists in the application and it is possible not to use templates at all.