# Nushell core team meeting 2022-06-15

## Attendees

Darren
Fernando
Jakub
Michael
Reilly
Stefan

# Topics

## nana

### Framework discussion
How do we want to deal with the change of Framework PR -> break it up into smaller commits to better follow along
Good comments on the pros and cons by the react PR contributor
Big plus for react: larger community of developers
https://github.com/nushell/nana/pull/32#issuecomment-1155636332

### Performance
Reilly explored different data grid views and compared it to a rust side implementation. Rust has performance benefits, not as heavy JS code, may also be somewhat portable in the logic right now?

How to load million entry datasets into HTML world (on local machines calling back into rust sounds cheap)

## Nushell data viewer TUI?

csvlens uses termion so not useful on windows

build it with crossterm ourselves sounds hard

tui-rs and console as higher level and seem to support crossterm as a backend as well

## NEW: Pipeline input and output types

Fernando added it for seemless dataframe commands but could be used for more

Dispatch based on input type matching in the **parser** (previous a `Map<name, impl>` now `Map<(name, type), impl>`) -> **static dispatch** so might allow compiler logic compared to dynamic dispatch (i.e. match statement in the command)

Pros:

Modularizes when adding new commands

(Maybe moves us to a richer parser so we can run just the parser for our LSP implementation)

Problem currently: duplication of help (avoidable when invoking help in a pipe `to-df | group-by --help`)
Idea: maybe have an abstract base command defining the core help message and core signature (OOP on the commands)

## Breakages with the nu release

### f5 reloads break with history

only on the first entry
Probably a little bug with initialization in `nu-cli/src/repl.rs`

## Little goal: Have a porting tool for history
either directly with the existing reedline history tools
or build with the sqlite nushell commands

## Despanning effort

Current PR feels stuck.
Doing this change will probably require a focussed phase with low PR merging activity and a lot of effort (and some good automation) to safely do that

We expect the performance improvements to be worth it, as there is a growth in "garbage" with a long running nu session (as well as local benefits due to cache friendlier smaller datastructures with the bare values)

Strategy: first try to replace the error labelling code with expression spans and call heads (see the impact on error quality and also removes code that will be broken by an automated refactor of the changes to value.)

## We are getting a package manager written in nu!!!

Changes to scripts for metadata will be necessary
Will be a great test playground for the nushell language (forces us to be more stable and performant!)