Efektywne tworzenie list w Dynamo: najpierw kształt danych, potem nody
Listy są sercem Dynamo. Jeżeli ich struktura jest spokojna, graf oddycha. Jeżeli poziomy zaczynają zmieniać się przypadkowo, nawet proste zadanie potrafi zamienić się w polowanie na błąd.
Flatten nie jest lekarstwem na wszystko
Flatten kusi, bo natychmiast porządkuje podgląd. Lista zagnieżdżona robi się płaska, nody zaczynają przyjmować dane, czerwone ostrzeżenia znikają. Tylko że razem z poziomami listy często znika informacja: który element należał do którego pomieszczenia, poziomu, typu albo grupy.
W automatyzacji BIM ta informacja bywa ważniejsza niż same elementy. Jeśli lista ścian jest pogrupowana według kondygnacji, to flatten może technicznie naprawić graf, ale biznesowo zepsuć wynik. Dlatego przed każdą operacją spłaszczania warto zapytać: czy tracę strukturę, która będzie potrzebna później?
Lacing jako decyzja projektowa
Dynamo daje różne sposoby łączenia list. W dokumentacji wygląda to jak techniczny detal, ale w praktyce jest to decyzja o relacji między danymi. Czy każdy element ma dostać jedną odpowiadającą wartość? Czy ostatnia wartość może być powtarzana? Czy potrzebujemy wszystkich kombinacji?
Jeśli nie nazwiesz tej decyzji, graf nazwie ją za Ciebie domyślnym zachowaniem. A domyślne zachowanie bywa dobre tylko do momentu, w którym model urośnie albo dane przyjdą z innego źródła.
List@Level daje kontrolę bez mnożenia nodów
W zagnieżdżonych listach bardzo łatwo zbudować długi łańcuch, który działa, ale przestaje być czytelny. List@Level jest jednym z tych mechanizmów, które warto rozumieć wcześnie, bo pozwala operować na właściwym poziomie danych bez rozwijania całej struktury na siłę.
To nie znaczy, że każdy graf ma używać tego wszędzie. Chodzi o świadomość, że lista ma poziomy, a operacja powinna działać na konkretnym poziomie. Jeżeli nie wiesz, na którym poziomie pracujesz, to prawdopodobnie debugujesz objaw, nie przyczynę.
Mały test przed dużym grafem
Zanim puszczę logikę na cały model, lubię zrobić mikropróbkę: trzy elementy, dwie grupy, jeden przypadek brzegowy. Jeśli graf działa tylko dla idealnej próbki, nie jest jeszcze gotowy do projektu. Dane projektowe rzadko są idealne.
Test listy powinien sprawdzać nie tylko wynik, ale też kształt: ile jest elementów, ile podlist, czy parowanie nadal ma sens, czy żadna operacja nie zgubiła relacji. To brzmi sucho, ale daje realny spokój przy automatyzacji.
Podsumowanie
Efektywne listy nie są efektem sprytu. Są efektem cierpliwego porządkowania danych. Najpierw struktura, potem operacje. Najpierw relacja, potem wynik. Im mniej przypadkowych transformacji, tym większa szansa, że graf będzie działał nie tylko dzisiaj, ale też po kolejnej zmianie modelu.