I am building an React+Redux application, I come to the point where I am
considering to use a container inside another container. I am asking myself if
this is a good approach, ie. is it good practice, or should we strictly follow the rule of 1 container with several components ?
Let me quote Dan Abramov's article about presentational- and container- components:
When you notice that some components don’t use the props they receive but merely forward them down and you have to rewire all those intermediate components any time the children need more data, it’s a good time to introduce some container components. This way you can get the data and the behavior props to the leaf components without burdening the unrelated components in the middle of the tree.
...meaning it is perfectly fine to have a container component inside another container component if you feel the need for it.
It's not easy to find which component should stay "dumb" and which component should be aware of application and become a container. I don't think it's a problem / anti-pattern to use a container in another one. If a part of your application is used on different pages it can be a container, be connected and use in differents pages/containers, Just be aware : this "container component" will specific to this application
Related
All:
I am pretty new to React. When a developer hands me a component to style, I always HAVE TO ask him to give me another html structure diagram of that component so that I can know what is going on inside it.
But when the component gets complicated(like multi level component nested, I may have to contact several diff developers to figure out the structure, expand the component and put them together to figure out the whole structure), I wonder if there is a better way to make this process a little easier(or if there is a standard guideline/spec for me to ask developers to fill out once they finish a component, so that I can get a quick picture which helps me to plan the style, esp the layout.)
Thanks
I am faced with a dilemma. I am writing components with nested components. What sort of coordinate system scheme should I implement? I want to be able to pass points to the components without having to worry about where the origin is in absolute terms. At the same time, I want to have some sort of encapsulation when it comes to origins and stuff.
Is there any sort of guideline to follow when it comes to nested components and such?
If I understand your question correctly you want to place a component in a sub-component in flex:
A point in Flex can be converted both to and from local ( in a sub component/ child ) via the globalToLocal and localToGlobal. While it by experience takes some fiddling to get it to work, it is possible. Issues can be with padding of components.
The guideline when it comes to nested components, is that you should try to minimize the nest-levels, as the layout engine suffers under deep nesting, because the layout mechanism is recursing..
For developing simple games with the Flex SDK, what are the consequences of using a Canvas object, versus a UIComponent object, as a drawing surface? Are there performance issues with either one? Are the methods generally the same? Searching around, it seems that most sample code I've found uses UIComponent. Is this just customary, or are there reasons?
I already know one odd difference - I had developed a simple Pong game using:
public class MyGameCanvas extends UIComponent
and then decided to replace UIComponent with Canvas. This caused the line to fail:
addChild(paddle);
After spending too many hours searching, I finally found that a Canvas object requires:
rawChildren.addChild(paddle);
due to the inheritance chain of objects, Sprites being higher than Canvas.
But that doesn't seem like a reason to prefer one class to another. Are there any specific reasons? Thanks.
Update:
Okay, I guess Canvas is out, and UIComponent is in. The only reason I even tried a Canvas object is the name. I mean, it's a Canvas - isn't that where you're supposed to do drawing? :)
So the second question that has popped up is about using the Flex SDK (and I don't know if this should be a totally new question, or here is okay).
However, I have to confirm something, being new to Flex and the various terminology. I'm presuming that people mean I should not be using MXML for games, when they said Flex SDK. Since I thought the Flex SDK was what provided the compiler that generates .swf files. Otherwise, where/how would I even compile AS3?
Assuming that's the case, then my question would be about the suitability of using both MXML and AS3 for (simple) games. Based on what I've read about both, it seemed like the intended use of them was MXML for the interface elements, and AS3 for everything else. Is the overhead that bad for MXML?
John C>
I think there is no point at all to use flex sdk to develop a game.
Flex SDK has been designed with application development in mind so you shouldn't use it to make games.
Do you have specific reasons to use it instead of a plain AS3 project?
Canvas has a bunch of extra layout code, plus scrollbars. It's definitely heavier than UIComponent alone. Also, it's important to know that Canvas requires all children to be subclasses of UIComponent. Using rawChildren to add non UIComponent is a hack unless you're building some sort of "chrome" for a Flex container (scrollbars on Canvas and the border/background in Panel).
I agree with PeZ, though. The Flex framework probably isn't the right choice for a game. Unless you have a game UI with things like DataGrids, Trees, Charts, etc., you can get a smaller and more optimized SWF without Flex.
If you dont need the additional stuff in canvas, like the scrollbars, that's clearly a reason to prefer UIComponent. Canvas is just an heavier object.
Inspired by this Flex question, is it seen as better practice to dispatch an event back to the parent app, as opposed to calling a method on the instance of the parent app, from within a module?
To me it seems that the module shouldn't know what methods are available at the parent, as such approach leads to tight coupling.
Thoughts?
I think I found my answer here.
Recently I found out that there are several things that one can do to massivly slowing down a Flex application. One of those things is the use of many nested layout containers. Another thing which is very problematic is the usage of lot's of relative positioning and sizes.
I do understand that there is a very big amount of calculations that must be done before the layout elements can be displayed. What I do not understand is why the rendering is done all the time. With a certain amount of complexity in your layout your CPU usage is 100% all the time even if there are no changes in the layout.
Why is that? And what can I do about that (without redoing the whole layout)?
Thanks a lot!
It is true that nested containers do slow things down, but I haven't yet been able to get the CPU usage up to 100% yet. The framework should only recalculate the layout of a component after its invalidateDisplayList() has been called. Calling this schedules a call to updateDisplayList, in which the layout of a container is calculated. Consequently, the display lists of the component's children are invalidated as well.
Besides doing it yourself, the displayList can be invalidated by the framework for a variety of reasons. For instance, it is always invalidated after invalidateProperties(). It could be that you have something that accidentally invalidates the display list of some high-level container all the time, thus propagating it down to its children.
Do you have any code to share? And what kind of a system are you running?
Any other solution other then refactoring your layout and not use many nested elements means change the way adobe framework works, and you do not want to do it !
My suggestion although might be painfull , change your view components , use absolute size and location where possible , do not nest too many elements .
The reason for the bottle neck with nested components is that the invalidate functions go 2 way , first up the tree from the changed component to the root , then from the root to all its nested elements , that whats taking your cpu .
Finally I found out what exactly the problem with our application was!
The problem was not that we used lot's of nested layout containers. I found out that there was a third party component that we use which attaches an event listener to the ENTER_FRAME-Event. Unfortunately this component does not shutdown properly so the event listener never gets removed. One thing this event triggers is a call to invalidateDisplayList(). I found out that the ENTER_FRAME-Event occurs very often (I still don't know why exactly this happens) and because of that the whole layout is recalculated over and over again. Because of the nested structure of our layouts this is a very time consuming thing to do and therefore the CPU gets very busy!
I could solve this problem by adding some extra code to the component that properly removes the event-listeners if they are no longer needed. The result of that has been that the application now does not need any CPU-power when in idle-mode. Hooray!!