We Keep Coding

Drawing list of components is slow reactjs

I have a list of components (~50-100), these components are quite advanced; they contain a lot of child elements that obviously takes some effort to be drawn out.
The result is that the UI "freezes" 1-2 seconds when navigating to the page, it actually freezes before getting to the page.
The UI is also a bit laggy when all the components are loaded.
I'm thinking it should be possible to load them in chunks in some way? Or only draw the full component out if it's visible on the screen somehow, and have a skeleton component when it's not in the viewport.
What is the recommended approach here?
Thanks in advance.

You must avoid useless renders with memo.
Be careful not to call APIs for no reason.
Also you should use useCallback and useMemo to avoid call methods which return same value for children components.
Context API is a good option to avoid Drilling states as props to nested components.
You could use lazy loading to render children components along with scroll as well.

React- is it better to conditionally render larger components or smaller children

If multiple components in a tree of components should render differently based on some shared data (current user, dark or light mode), is it better to create different higher level large components that conditionally render? Or is it better the have the lower level small components conditionally render?
For example, lets say I have a <ProfileSection> component made up of many smaller components like <Avatar>, <CoverImage> etc..
When the current user of the profile is logged in, it should render with edit buttons like this:
Is it better to conditionally render two different profile sections?
{isAuth ? <EditableProfileSection>:<ProfileSection>}
Or is better to render one <ProfileSection> and conditionally render its children using react context
Ex:
{ isAuth && <EditProfileButton>}
{isAuth ? <EditableAvatar> : <Avatar>}
It feels like the second way is more correct because if you had two different higher level components they could get out of sync if you made changes to one. I think I just answered my question... I guess I'll post this anyways because maybe it will help someone.

How to measure a large number of components in React Native without causing an error?

I'm trying to implement a generic Drag-and-Drop module that I may or may not release on NPM.
I took inspiration from an already existing DnD module which consisted of essentially two main components: Draggables and DropZones.
The Draggable components would enable any content that they enclosed to be dragged around, and DropZones were the components that would react to when a Draggable component was dragged in/out of them and/or dropped onto them.
The module's functionality was too basic for what I needed, so I set off on making my own.
Everything has been going fine except for one aspect: measuring the absolute position of a large number of components in order to find their corresponding bounding shapes for collision detection.
Currently, I've been using the View's measure method to measure the absolute position and size of my components, however, if you call this method too many times within a short period of time, React Native will throw this error: Warning: Please report: Excessive number of pending callbacks: 501. Some pending callbacks that might have leaked by never being called from native code and it lists the offending method as {"module":"UIManager","method":"measure"}.
If I make a basic for loop that repeatedly calls the measure method, I can get it up to just over 500 iterations before React Native complains (this number may be hardware-dependent; I'm not sure).
Also, the same problem happens when using the View's other measuring methods (e.g. measureInWindow, measureLayout).
What's even worse is that up until now, I have been calling the measure method in a View's onLayout callback, however, I recently discovered that onLayout does not get called when a style changes that doesn't directly affect the given View (such as when a parent component's margin changes).
This means that the given components can be re-positioned (relative to the screen) without them knowing about it.
Because of this I will have to use a different means of notifying my components that they need to remeasure themselves.
I thought about using some of the life-cycle methods that pertain to component updates, but that would most likely be even worse, because most of them get called every time the component updates which is far more often than a layout happens.
Edit: One other problem with using the life-cycle methods that pertain to component updates is if a parent component prevents it's child components from being updated (such as through shouldComponentUpdate).

Angular 4 - it is more expensive to handle styles of a generic component or work with specific components

I'm working on a hybrid application for which I need a toolbar. This toolbar must handle different forms and functionalities, in some cases contains a title, other buttons and links and in others an autocomplete, then my questions is if is more efficient to build a dynamic component that accepts all these elements or work on different toolbar's that will be inserted and removed from the DOM as needed.
Thanks!

A dynamic toolbar will be faster, because angular wont need to re-render the whole toolbar each time it changes. It's smart enough just to find the stuff it needs to update.
Also it will make your code easier to maintain I think. Having multiple toolbars, probably with some shared logic/elements will cause repeated code.
Also you will probably have less lines of code with a dynamic toolbar, perhaps slightly reducing the size of your project. I suspect that wont be significant. Honestly, I think the biggest advantage wont be speed but cleaner, more maintainable code in general.

It depends on whether you are using lazy loading or bundling your entire App in one main.bundle.js
In the first case, you want to ship the strict minimum to the browser as it's needed. Therefore, you want separate component for each use case.
In the second case, it makes your app lighter to create on single component to handle different toolbar use cases.
To demonstrate this, (assuming you're not using lazy loading) you can create a small project with a main component which uses 2 different views.
In one case you create a single component for each view.
In the other you combine both views in one component.
Then build and serve both and you can see the difference in the weight of your JS files.
Hope this helps

Completely different view for mobile

I have a SPA that needs to display my app in two completely different ways depending on the client device.
One shows a floorplan of my house with lightbulb icons to switch on/off my lights (and later on more information), rendered on a canvas using isometric projection.
The other (mostly for mobile) shows the same lightbulb icons alongside a name in a simpler list/hamburger menu.
I don't want to limit either device-type to the view I intended, but what is the best way of completely replacing the component based on device/selected view?
Should I create two components and move shared logic to services/classes? Or should I hide the unneeded component (I don't want to waste resources rendering the canvas or running the logic needed to render it)

If you use *ngIf or similar, then there is nothing rendered if the expression is false while [hidden]="..." causes HTML to be rendered.
Moving logic to services is a good practice anyway.
You could also load different router configuration depending on the view size
See also New Angular2 router configuration. This way you could load entirely different components for different view sizes.
(It looks like this will be improved in next versions for example to only load new child routes for a component, there are also discussions to provide an API to allow to add/remove single routes)