Hola, I’m Hieu, a Software Engineer

Bạn hẳn từng gặp tình huống này. Thiết kế là một feed masonry hai cột: các card cao thấp khác nhau, mỗi card mới rơi vào cột nào đang ngắn nhất, thỉnh thoảng chen một banner chiếm trọn chiều ngang. Bạn thử Wrap — mỗi hàng lấy chiều cao của child cao nhất, thế là hở khoảng trắng. Bạn thử hai Column trong một Row rồi tự chia danh sách — nhưng không thể chia đúng nếu chưa biết mỗi card render ra cao bao nhiêu, mà điều đó chỉ biết được sau khi layout. Bạn thử Stack với Positioned , và bây giờ bạn cần chiều cao của từng card dưới dạng con số, ngay trong build, trước khi có gì được đo. Cái bẫy nằm ở chỗ tất cả đều là câu trả lời kiểu ghép widget cho một bài toán đo đạc . Row, Column, Stack, Wrap bản thân chúng là các render object với thuật toán layout cố định. Lồng chúng vào nhau không tạo ra thuật toán mới; nó chỉ tạo ra một cây cao hơn chạy đúng ba thuật toán cũ. Khi hình dạng bạn cần thực sự là một thuật toán khác — một quyết định đặt vị trí phụ thuộc vào kích thước đã đo của các s...

You know the moment. The design is a two-column masonry feed: cards of different heights, each new card dropping into whichever column is currently shortest, with the occasional full-width banner cutting across both. You try Wrap — every row gets the height of its tallest child, so you get gaps. You try two Column s inside a Row and split the list yourself — but you cannot split it correctly without knowing how tall each card renders, and you only know that after layout. You try Stack with Positioned , and now you need every card’s height as a number, in the build method, before anything has been measured. The trap is that these are all composition answers to a measurement problem. Row, Column, Stack and Wrap are themselves render objects with fixed layout algorithms. Nesting them does not produce a new algorithm; it produces a taller tree running the same three algorithms. When the shape you need is genuinely a different algorithm — a placement decision that depends on the measu...