YoannBuch
commented
5 years ago Hi Anthony,
Thanks for the great feedback.
I totally agree with you. Flow is missing an abstraction on top of packages/classes to get closer to the user's mental model: layers, components, etc. Layers could be either materialized as colors like you suggested or as containers (e.g. boxes) for packages/classes/methods.
There could be different ways to define these layers.
Flow could support some sort of configuration where layers are defined by matching package or class names, like it was done for the filtering capability. Example: "Entities" => all classes matching "com.acme.entities.*" + yellow color ...
Custom annotations would work too:
@FlowLayer({name="Entities", color="yellow"}) public class MyEntity { }
I personally prefer the configuration approach as it would allow the architecture to be reflected in Flow without too much maintenance.
Then comes the question of stability, and I agree this is very important.
- Flow could let users move around layers or classes on the map, and retain the last position
- Positioning could be given in the configuration or the annotations
Automatic position seems really hard at this level of abstraction and therefore I feel like the user should be able to tell Flow the best where to position everything.
Is it close to what you had in mind or were you thinking of something else?
All that is very exciting but I have to say that I haven't been able to improve Flow over the last year as I no longer have the time for it :(
Yoann
On Mon, Dec 10, 2018 at 11:38 AM anthonyleonard notifications@github.com wrote:
Firstly, flow is awesome :)
Nevertheless, I wanted to share a thought that I had about custom layouts in Flow ...
The auto generated layouts that Flow provides is perfect when you lack any context about "where a class lives" in your codebase. However many codebases are consciously split into layers or subsystems. ( In our case we use an "clean" architecture in which every class lives in a layer a la http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html ) It would be great if we would use Flow to show diagrammatically which classes are called in the context of these layers. For this reason I would like to tell Flow where in a diagram a given class should be placed, and what colour it should have. This way it would be easier to see that some unit tests only call certain subset of classes, integration tests call classes at the edge, service tests cover the whole thing, etc. Also show the "flow" (literally) through the layers when calls are made while the app is running. This would be particularly helpful for new starters on the team or QAs being tasked with understanding the code coverage of our tests.
Keeping a class in the same place on a diagram every time, and with the same colour every time also helps the team gather a stable mental picture of the architecture. This stability is impossible if the class keeps jumping around for each different test when the colour and position are determined programmatically (albeit very cleverly to make very pretty diagrams) in the absence of any any other context.
It occurred to me that custom annotations on classes providing the x y coordinates (relatively sized?) and rgb colour codes might allow Flow to register these and layout its diagrams accordingly.
If I get time I will be exploring ways of achieving this myself, but I thought I'd share for now. Let me know what you think :)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/findtheflow/Feedback/issues/46, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfWhb8PHaTpF-8Y2FTp2ypzvGAULEQsks5u3jmQgaJpZM4ZLFkc .
Firstly, flow is awesome :)
Nevertheless, I wanted to share a thought that I had about custom layouts in Flow ...
The auto generated layouts that Flow provides is perfect when you lack any context about "where a class lives" in your codebase. However many codebases are consciously split into layers or subsystems. ( In our case we use an "clean" architecture in which every class lives in a layer a la http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html ) It would be great if we would use Flow to show diagrammatically which classes are called in the context of these layers. For this reason I would like to tell Flow where in a diagram a given class should be placed, and what colour it should have. This way it would be easier to see that some unit tests only call certain subset of classes, integration tests call classes at the edge, service tests cover the whole thing, etc. Also show the "flow" (literally) through the layers when calls are made while the app is running. This would be particularly helpful for new starters on the team or QAs being tasked with understanding the code coverage of our tests.
Keeping a class in the same place on a diagram every time, and with the same colour every time also helps the team gather a stable mental picture of the architecture. This stability is impossible if the class keeps jumping around for each different test when the colour and position are determined programmatically (albeit very cleverly to make very pretty diagrams) in the absence of any any other context.
It occurred to me that custom annotations on classes providing the x y coordinates (relatively sized?) and rgb colour codes might allow Flow to register these and layout its diagrams accordingly.
If I get time I will be exploring ways of achieving this myself, but I thought I'd share for now. Let me know what you think :)