dragEnter and dragLeave have the same problem as mouseIn and mouseOut events – if the drop target has children elements, dragEnter and dragLeave events fire when your mouse is crossing boundaries of those children elements.
The solution? One is pointer-events:none for the children elements. The other is to manually count the dragEnter (counter++) and dragLeave events(counter–), and declare a true mouseLeave only when the counter returns to zero.
HTML5 drag and drag API are pretty tricky to use …
Have been using so much Firebase and tried different ways of doing One-to-N. I found this paragraph from Mongo summarized it well.
Embed the N side if the cardinality is one-to-few and there is no need to access the embedded object outside the context of the parent object
Use an array of references to the N-side objects if the cardinality is one-to-many or if the N-side objects should stand alone for any reasons
Use a reference to the One-side in the N-side objects if the cardinality is one-to-squillions
Pretty annoyed by the dramatic changes in different version of React Router. Have already updated my app like three times due to breaking API changes…
Still struggling to get Flux to work with ReactRouter. The only thing I found useful is this article.
Maybe the question is: do we need a router and a Flux store? It seems like we only need one of them.
I was initially shocked by how ‘naive’ the Express.js was in terms of dealing with routes. After initial shock, I wasn’t sure whether there is an easy alternative. So I went through the comments of the original blog, and realized it is indeed a deliberate choice made by the framework.
However, the damage has been done to the Express framework. I imagine this article would be brought-up many times in the future. The conversation would go like ‘No. We shouldn’t use Express. Didn’t you see how Netflix was ditching Express?’. Quite similar to when Facebook ditched HTML and went for native, maybe at a much smaller scale.
I used to have a lot of respect for engineering blogs from different companies. After all, you are supposed to demonstrate the technical leadership. But this article serves as a friendly reminder that things are not so simple as it seems.
Flexbox is very powerful, yet still not popular enough.
Look at this
This is the shorthand for flex-grow, flex-shrink and flex-basis combined. The second and third parameters (flex-shrink and flex-basis) are optional. Default is 0 1 auto.
Guess what does this mean?
– flex: 1 auto;
How about this
– flex: 2 0px;
The first one means
The second one means
Is auto the same as 0px? No.
StackOverflow says “flex-basis allows you to specify the initial/starting size of the element, before anything else is computed. It can either be a percentage or an absolute value.”
But why would a box’s final size depends on its starting size though? I thought that was the whole point of having flex-grow… Need to meditate on this one…
Maybe because of this ‘flex-basis establishes the base width of the element prior to redistributing remaining space along the (main?) axis, either by justify-content or flex-grow/shrink values’. (also from StackOverflow)
Not a CSS guru, but flexbox make it really easy
container use display:flex, and item use margin:auto
container use display:flex, justify-content:center, align-items:center. Here justify-content positions items in the main-axis of the flex(default in the row direction), and align-items positions items in the axis that is orthogonal to the main-axis