Sweet editor, I can already think of a few good use cases to use on a couple projects
groby_b 35 days ago [-]
This looks interesting - looking forward to see where it heads!
An entirely nitpicky nitpick: The demo GIF rubs me the wrong way. I know, you want to show of all the features quickly, but what I see when I watch it is a reviewer who doesn't actually read the code, just clicks "reviewed" everywhere, and throws in a slightly patronizing "Good job!"
If you have a moment, you might want to think about a flow that's better at demonstrating how it improves code reviews delivered.
But, as I said, nitpick. There's a lot of potential here!
akshaysg 35 days ago [-]
Good point! Yeah I think I should record myself doing an actual review while balancing showing the complete feature set.
Thank you!
rwparris2 35 days ago [-]
Looks great!
I'll be looking out for gitlab integration
akshaysg 34 days ago [-]
I'll let you know when we have this up!
midnightmonster 34 days ago [-]
I think I understand what it does and it looks interesting and appealing. My team would need Ruby support. Not sure if you'll be able to connect the graph properly in Ruby, but it might still be useful.
watercolorblind 34 days ago [-]
We would need ruby support too.
Beyond that, if my MR/PR has two (or more) logical commits, will the tool support reviewing each in isolation? Often times, I will do a refactor in the first commit, and have a second commit with the new feature that makes use of the refactor. Reviewing it all together can result in muddying the water.
Another thought: if I edit a function to call a different function defined elsewhere in my codebase, is there a way to include that functions definition into the canvas (either by the author in preparation for a reviewer, or by the reviewer) to facilitate verifying the behavior across this new boundary?
akshaysg 34 days ago [-]
You can review each commit in isolation! Also, you can CMD+Click on that new function and it should create a view of that function on the canvas, along with a connector.
akshaysg 27 days ago [-]
Ruby is now supported on Haystack!
akshaysg 27 days ago [-]
Ruby is now supported on Haystack and it should have a graph connected correctly!
akshaysg 34 days ago [-]
We can get it working with Ruby ASAP!
jerryhomelab 35 days ago [-]
What does it do apart from the call graph? If I had jump-to-definition and find-references in the line-by-line code review UI, what extra benefits would I have by using Haystack?
akshaysg 34 days ago [-]
> If I had jump-to-definition and find-references in the line-by-line code review UI
I think the main benefit of Haystack is that it allows you to keep a model of how the pull request works on the canvas, rather than manually needing to gain an understanding of it in your head.
Even with goto definition/references, I need to understand what parts of the pull request are net new and work together (e.g. I created a new function A that relies on a new class B and calls a new function C) and what parts are linked with existing parts of the codebase.
Normally, this would require me to do some digging around, but with Haystack a lot of this work is done for me in a visual way, allowing me to understand a pull request significantly faster.
hemc4 34 days ago [-]
This is promising.
Does it works on local without any login? I review github pull requests in vscode and this seems extention of that workflow where I can visualise the PR
akshaysg 34 days ago [-]
As of now, you need to log in on desktop to review pull requests. Theoretically, we would not require login if your pull requests are in a public repo. If that's the case, I can get a change in for this ASAP!
EDIT: By log in, I mean you have to log in to GitHub. There's no separate Haystack log in.
afatparakeet 31 days ago [-]
Looks really great! I'm definitely interested in self hosting
etwigg 35 days ago [-]
This looks incredible! How does language support work? (I'm curious about Kotlin in particular)
akshaysg 35 days ago [-]
Language support relies on the same language servers that VS Code uses (i.e. language extensions)! Servers come pre-installed with a variety of extensions, but I believe we do not install Kotlin for now. We'll get Kotlin installed (this was just an oversight)!
Kkoala 35 days ago [-]
Maybe this is not for me, but I don't understand what it does
What do those groups and arrows mean?
akshaysg 35 days ago [-]
If you don't understand what it does the fault is all mine!
The arrows represent dependencies. For example, if you create a function A that calls a function B in a pull request:
1. We'll render function A as a diff on the top part of the canvas
2. We'll render function B as a diff on the bottom part of the canvas
And we'll draw an arrow from A to B, to represent that A is calling B
In this way, you can more easily understand the relationships between different parts of what someone is editing. We hope that this reduces the amount of mental modeling or mapping someone has to do during code review!
hassleblad23 35 days ago [-]
I have always wanted to do something like this! Great work.
samactionbase 35 days ago [-]
Nice job guys!
Rendered at 23:04:48 GMT+0000 (Coordinated Universal Time) with Vercel.
An entirely nitpicky nitpick: The demo GIF rubs me the wrong way. I know, you want to show of all the features quickly, but what I see when I watch it is a reviewer who doesn't actually read the code, just clicks "reviewed" everywhere, and throws in a slightly patronizing "Good job!"
If you have a moment, you might want to think about a flow that's better at demonstrating how it improves code reviews delivered.
But, as I said, nitpick. There's a lot of potential here!
Thank you!
I'll be looking out for gitlab integration
Beyond that, if my MR/PR has two (or more) logical commits, will the tool support reviewing each in isolation? Often times, I will do a refactor in the first commit, and have a second commit with the new feature that makes use of the refactor. Reviewing it all together can result in muddying the water.
Another thought: if I edit a function to call a different function defined elsewhere in my codebase, is there a way to include that functions definition into the canvas (either by the author in preparation for a reviewer, or by the reviewer) to facilitate verifying the behavior across this new boundary?
I think the main benefit of Haystack is that it allows you to keep a model of how the pull request works on the canvas, rather than manually needing to gain an understanding of it in your head.
Even with goto definition/references, I need to understand what parts of the pull request are net new and work together (e.g. I created a new function A that relies on a new class B and calls a new function C) and what parts are linked with existing parts of the codebase.
Normally, this would require me to do some digging around, but with Haystack a lot of this work is done for me in a visual way, allowing me to understand a pull request significantly faster.
Does it works on local without any login? I review github pull requests in vscode and this seems extention of that workflow where I can visualise the PR
EDIT: By log in, I mean you have to log in to GitHub. There's no separate Haystack log in.
What do those groups and arrows mean?
The arrows represent dependencies. For example, if you create a function A that calls a function B in a pull request: 1. We'll render function A as a diff on the top part of the canvas 2. We'll render function B as a diff on the bottom part of the canvas And we'll draw an arrow from A to B, to represent that A is calling B
In this way, you can more easily understand the relationships between different parts of what someone is editing. We hope that this reduces the amount of mental modeling or mapping someone has to do during code review!