alex-grover/model-visualizer

An easy way to create a visual of the model structure in your Rails projects.

Hey, I'm Alex. I'm a software engineer and photographer. I'm currently working on Homage. We are on a mission to make the most expensive NFT art more accessible.

Before Homage, led the Platform team at Darwin Homes, where I joined as an early engineer. Darwin was acquired by Pagaya in January 2023.

Before Darwin, I spent time traveling in Southeast Asia, freelancing and honing my creative skills as a photographer.

I studied Computer Science at Stanford, and started my career as the 13th engineer at DoorDash, where I helped start the Merchant, Payments, and Drive (b2b white label delivery) teams.

When I'm not drinking coffee and building websites, you can find me outside, traveling, taking photos, and looking for a new adventure.

📬 Find me on the internet: alexgrover.me/links

model-visualizer's Issues

Display node names on generated page

Larger nodes and easy to read names for ease of use.

Better way to display HTML output

We should come up with a better way to show users the output rather than just spitting out a file they have to open. I know on a Mac, there is an open command available at the command line that will open a file with the correct program.

We should look into this to see if it is available on all platforms or if there is a way to launch a browser from Ruby so the user does not have to open it manually. I was also thinking about embedding a web server in the gem that displays the page but that might be overkill for a single static file.

Handle ActiveRecord self-joining associations

We need to make sure to include associations with different names than the class. Rails allows you to do things like has_one :manager, :class_name => 'User' which basically inserts a relation for a User but names it manager for easy access on the model object.

This simply involves a little more work on the model-parser. For now, we are just skipping and relations like these that we encounter but they are necessary to include.

Node detail view

Feature that has been discussed: it would be nice to have the main page show the full network of models and then allow details, properties, etc. to be viewed on mouseover or when a node is clicked through a tooltip or sidebar or zoom in. This would allow the main view to remain uncluttered while still allowing access to all the information about any node.

We should discuss the visual design here but I think that this feature is necessary before this is ready for use.

Pretty display schema attributes

should be easy - I think the best way is to change how the data is JSON-ized on the backend to look nice and readable rather than be in snake_case. This would be a UI improvement by itself.

Include d3.js script locally

It should be included locally so the user does not need an internet connection to run our gem. This also allows us to lock down the version we are using in case d3 introduces breaking changes.

Resize window to not include sidebar

as per design, calculate appropriate SVG size in window. right now the sidebar overlaps the nodes.

Use issues to keep track of, discuss and rank future enhancement ideas

Update documentation

To include arguments and usage information. Also, document all edge cases regarding file locations, etc

JSON Format

Need to figure out what is the optimal format of model data to pass into the visualizer such that we aren't wasting time re-parsing anything from a string format, or using an inefficient sort/search in order to display each node with its [association] edges.

Factor javascript and HTML into own file

Rather than encoding the output page and script in a big string, we should eventually have a template HTML page and a .js file that it includes that handles all the D3 logic. We would then simply have the visualizer serialize the data and pass it to that page. This allows us to test and edit our javascript code more easily as it will become unmanageable at some point if it is just a string.

D3 script not working for windows dev-box.

In share/template.html the line <script src="<%= @d3 %>" charset="utf-8"></script> including the D3 script does not work properly when in the devbox. Instead of including /vagrant/... it includes /home/vagrant/... This may not be much of an issue because it's on the dev-box, but I'm bringing it up anyway.

Restrict nodes to being displayed in window

Currently, they can be outside of the window. Seems like using Math.min/max could potentially fix this.

http://stackoverflow.com/questions/9573178/d3-force-directed-layout-with-bounding-box

More robust model and schema parsers

Following @Sxl1092 's email - the parser fails if we have lines with the substring class that are not actually defining a class. It also fails for schemas with attributes defined because the regex does not match the trailing comma. We need to make the parser more robust to handle all types of files.

This could potentially be done by using the regex to test for class definitions rather than line.include? and check that the returned match is not nil.

We should get this done by next Tuesday, 5/5.

Fix sidebar highlight

if you click a model multiple times then another model the original one fades out incorrectly

Allow users to pass options at the command line

Things like --help as well as a path to the Rails root:

Ex: $ model-visualizer ../fulcrum

Where the gem would generate the HTML page in the current directory but parse relative to the passed path. At the very least, this would be useful for us for testing.

Handle Rails autogenerated properties

Rails has some tables that are generated automatically (tags and slug are a few of them I believe) that we should not be including in our visualization. There are also properties on individual models that are generated automatically.

I think it makes the most sense to show only models and properties that were added by the developers. However, this is up for debate as these are usable to query by in your Rails app. Let me know what you all think.