Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nteract as a web app #1346

Closed
9 of 10 tasks
rgbkrk opened this issue Jan 17, 2017 · 11 comments
Closed
9 of 10 tasks

nteract as a web app #1346

rgbkrk opened this issue Jan 17, 2017 · 11 comments
Labels
outdated workflow: issue should stay closed

Comments

@rgbkrk
Copy link
Member

rgbkrk commented Jan 17, 2017

This is a bit of a high level overview of what we need to make nteract available as a web application in addition to components and modules for people to build their own (see #301) or for using our transforms in a standard way in JupyterLab (as @gnestor has done by grabbing the code and maintaining separately).

We ended up bringing in react-jupyter-display-area as well as react-transformime into this repository which helped us iterate faster and create a tighter build. We swore that we would export these again as part of a monorepo and that time is certainly upon us.

Here's how I imagine this repository will become laid out, as a top level:

packages/ # lerna style modules
electronApp/ # uses the lerna modules to compose the electron app
webApp/ # uses the lerna modules to compose a web app

My assumption is that the web app will build upon the jupyter notebook server. I'm (personally) not trying to support a standalone single user server for nteract, the primary reason I think I have to build a standalone frontend is to make sure that the exported components are useful while working on a multi user server.

Precursors

In order to ease maintenance burden of these modules, we've been decoupling components and reducers while also stabilizing our base. In progress issues:

Web app necessities

Monorepo

This may need to be done in stages to minimize pain. Suggested pathway:

  • Export everything as a mega lerna package
  • Extract smaller and smaller pieces that are decoupled
    • commutable
    • transforms
    • display area

I'll continue to update the above with an outline as we push towards this. What else is a necessity here?

@peggyrayzis
Copy link
Member

peggyrayzis commented Jan 17, 2017

After the provider refactor, I think we should spend some time making our components more composable. Right now, we make a lot of assumptions about what a notebook should and should not have. For example, we embed the StatusBar into the Notebook but what if the end user wants to embed their own status bar? What if the user wants to display different buttons in the Cell Creator menu? Today, we don't support either of those use cases. I really like Victory as an example of a completely composable library - it makes no assumptions on what is included in a chart and leaves the decision completely up to the user.

We should also think about integrating our CSS into JS to allow users to pass in custom styles through a style prop that will override our defaults. I'm most familiar with Aphrodite because it's really similar to React Native StyleSheet, but I'm open to any other libraries here. Here's an example of what it would look like:

// our default
const ColoredDiv = ({}) => <div style={styles.coloredDiv} />
const styles = StyleSheet.create({ coloredDiv: { backgroundColor: 'red' } })

// we can concatenate their styles passed through the style prop onto our existing styles (it can take an array)
// it works like object assign so whatever is last is what is rendered
<ColoredDiv style={{backgroundColor: 'blue'}} />
// div will render blue

@rgbkrk
Copy link
Member Author

rgbkrk commented Jan 17, 2017

After the provider refactor, I think we should spend some time making our components more composable.

Totally agree.

For example, we embed the StatusBar into the Notebook but what if the end user wants to embed their own status bar?

Yeah I think the status bar will probably be way different for a web app. I'm guessing the <Notebook /> component shouldn't even have the status bar - it should be some higher component up that looks more like this for the opinionated electron notebook (note: as structure, not as the actual components):

<App>
  <Notebook />
  <StatusBar />
</App>

The pinned cell(s) could be outside of <Notebook /> here too. As long as configuration is composability rather than inheritance (yay for functional principles that React leans towards) then I'm happy (you can easily get me to rant about ultra-configurability).

@rgbkrk
Copy link
Member Author

rgbkrk commented Jan 17, 2017

I'll have to spend some time learning about how we'll package / use CSS in that way. I've been really happy with our theming stylesheets and have lately wondered how we're going to expose the current styles in a good way.

@theengineear
Copy link
Contributor

@rgbkrk just catching up on this issue and trying to get some bearings. I'm mostly just trying to learn more about how the repo is organized and such.

Some responses

Precursors > Refactor components to remove Redux logic

If I'm understanding this right, you're looking to pass down dispatch-y props to child components? I've found that using connect and just defining mapStateToProps and mapDispatchToProps liberally helps keep logic inside the file you'd like it to be in. I.e., if you end up interacting with a component and something breaks, it's more likely that the problem is in that component file. I also prefer this for tests. Anyways, just some thoughts.

We should also think about integrating our CSS into JS to allow users to pass in custom styles through a style prop that will override our defaults.

I wonder if in-lining styles will couple React code a little too tightly with the style? I'm not sure how you're planning on doing the overriding of things, but a well-organized set of scss files (using the 7-1 pattern https://sass-guidelin.es/) can be pretty clean! That said, I've never actually tried doing css --> js and have blindly followed articles like this.

Extras

Also, you'd mentioned something about creating menu mocks / components. Is the intention to create this from scratch (at some level), or just rely on some 3rd party menu?

@rgbkrk
Copy link
Member Author

rgbkrk commented Jan 18, 2017

you're looking to pass down dispatch-y props to child components

Yep, that's what folks are currently tackling as PRs for #1288.

I wonder if in-lining styles will couple React code a little too tightly with the style?

I'm a little afraid of this too, though I think it's not a decision that will paralyze us. We can always change it again later as many of these function more like a library than a site we run. The pressures will likely come from us using nteract components in different fashions.

Also, you'd mentioned something about creating menu mocks / components. Is the intention to create this from scratch (at some level), or just rely on some 3rd party menu?

If the 3rd party menu works, I'd much prefer to rely on something well supported by others. 👍 As long as we can style it similarly to the rest of our theme(s), branding, and experience I'm certainly game.

@rgbkrk
Copy link
Member Author

rgbkrk commented Jan 18, 2017

Ah, I see you linked a context menu (amusingly, we did use this one a few months ago). The menu mocks I'm talking about are top level app style for documents:

Jupyter

screen shot 2017-01-18 at 9 26 49 am

Google Docs

screen shot 2017-01-18 at 9 27 22 am

Alternatively, there's the sidebar nav approach:

Databricks

screen shot 2017-01-18 at 9 28 15 am

@rgbkrk
Copy link
Member Author

rgbkrk commented Jan 18, 2017

Quick mock for nteract:

nteract web app

I'll post a Sketch file from that to https://github.com/nteract/mocks as well as one for the dashboard view.

@rgbkrk
Copy link
Member Author

rgbkrk commented Jan 19, 2017

As promised: nteract/design#14

@theengineear
Copy link
Contributor

theengineear commented Jan 19, 2017

Re: top-nav or side nav, I definitely think top-nav is the way to go. I feel like horizontal space is always at a premium when I'm in a notebook.

@theengineear
Copy link
Contributor

If the 3rd party menu works, I'd much prefer to rely on something well supported by others.

👍 👍 I think requirement here should be reasonably simple, I'd be surprised if an acceptable solution doesn't exist.

@rgbkrk rgbkrk added this to the (A-2) Avicular Avicenna Alpha milestone Feb 7, 2017
@rgbkrk rgbkrk removed this from the (next) Avicular Avicenna Alpha milestone Feb 27, 2017
@rgbkrk
Copy link
Member Author

rgbkrk commented Apr 3, 2018

Just an update -- there is now a web version of nteract that runs on top of the jupyter server. You can try it out on binder!

The jupyter extension is called nteract_on_jupyter on PyPI and there are install instructions here: https://github.com/nteract/nteract/tree/master/applications/jupyter-extension

@rgbkrk rgbkrk closed this as completed Apr 3, 2018
@lock lock bot added the outdated workflow: issue should stay closed label Jul 4, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jul 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated workflow: issue should stay closed
Projects
None yet
Development

No branches or pull requests

3 participants