Github: Put the view into a Dock

[maxbrunsfeld]

Now that https://github.com/atom/atom/pull/13977 has landed, we need to put both the tree-view and the github package's view into a dock. This will improve the experience of using the github package in conjunction with features like Nuclide's debugger, which also create a right dock item.

[simurai]

put the github package's view into a dock

I was thinking of having the Git and Hub as two separate dock items.

So we wouldn't need the segmented controls anymore. Also new views like the branches would also be its own dock item. Then it's super flexible to arrange them to your personal workflow. For example you could move the branches to the left together with the tree-view or even have them side by side or stacked. 😻

[smashwilson]

:heart:

Do we want to wait for docks to land in a release first? Beta or stable? We do have users from the staff ship already.

Or maybe we could condition it on a runtime probe for the docks API 🤔

[BinaryMuse]

Yeah I think we'll want dual code paths until we bundle 👍

On Apr 1, 2017 7:49 AM, "Ash Wilson" [e-mail] wrote:

❤️

Do we want to wait for docks to land in a release first? Beta or stable?
We do have users from the staff ship already.

Or maybe we could condition it on a runtime probe for the docks API 🤔

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/atom/github/issues/629#issuecomment-290924651, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALkpvVcFWBKzJEIlWL7BjuNW82ZXBBzks5rrmPmgaJpZM4Mu4XG
.

[BinaryMuse]

I started looking into this today. One relatively immediate problem is that we manage our Panel items directly with React, passing in props from local component state, rather than using URIs. It seems that using URIs would require us to have some global model that indicates what the current repository is, which I'd like to avoid if possible.

Is there a good way we could use the new dock API with items directly, other than going through the Dock APIs ourselves?

/cc @nathansobo @matthewwithanm

[nathansobo]

@BinaryMuse Because docks wrap PaneContainer instances, the same imperative APIs for managing pane items within docks do exist, but I really think we should try to make it work with the URI based system. The reason is that the URI based system allows users to drag dock items around and have Atom remember this state across sessions rather than hard coding this logic into the package. Maybe we can address your specific concerns and improve the APIs however. @matthewwithanm may have more to add.

[matthewwithanm]

@BinaryMuse Is the issue that you need some way of pushing the active repository to the view somehow? (Sorry, this is the first time I'm looking at this code 😬)

Since the opener and deserializer both can go in the main module, you could just store references and continue to push updates to the view that way, right?

The model approach is what we usually do in Nuclide though. But we use an observable and then use an HOC to wrap a dumb component to re-render on every change, so everything stays nice and clean. So like states is an Observable<{activeRepository: Repository}> and DumbThing is a component that accepts an activeRepository prop. Then we do StatefulThing = bindObservableAsProps(states, DumbThing) and render that. Not sure if that helps at all 🤔

[BinaryMuse]

@matthewwithanm That's basically correct, yes. In this code you can see how we declaratively manage the Panel and its contained item, and we pass a considerable amount of props (including refrences to component local state and methods on the component) into the GitTabController.

I'm still thinking through this, but the way I understand it is there are two code paths we need to handle:

1. The side dock item is added to the Dock via atom.workspace.open and the component generation is handled via an Atom URI opener. In this case, the package is already activated and we've already rendered the RootController, so it can be responsible for managing the opener (e.g. maybe via something like #635). Since RootController is responsible for creating the item, we can allow it to pass in the props via React's declarative props.
2. Atom is being reloaded or the side dock item is otherwise being hydrated from a deserialize call. In this case, the package may not yet have been activated, so the RootController instance does not yet exist. In this case, we need to somehow generate an item to put into the dock and later attach it to the RootController so it can send in the props.

Does this seem accurate? If so, I can think of a few potential mechanisms that we could use to make this work. I'll experiment with them and see how they fare.

[matthewwithanm]

1. Atom is being reloaded or the side dock item is otherwise being hydrated from a deserialize call. In this case, the package may not yet have been activated,

oh! we had that issue too so we added an initialize() hook: atom/atom#13358

i haven't quite wrapped my head around adding openers in a React component yet, would that still be necessary? how we do it is to create our store/model in initialize() and then create that bound stateful view i mentioned above in the opener and deserializer. that way we don't even need to worry about imperatively re-rendering (like in github-package).

[BinaryMuse]

Closed by https://github.com/atom/github/pull/664