Giter Site home page Giter Site logo

slumber's People

Contributors

lucaspickering avatar

Stargazers

avatar avatar

Watchers

avatar

slumber's Issues

Text box consumes ctrl-c

Ctrl-c should gets its own view message, so it can't be consumed accidentally by anything that eats input

Add `command` source fo chains 

chains:
  id: command
  source: !command echo hello

This would be useful for grabbing external values that aren't in files or env variables, e.g. current kube context

Move config into a file

Having configuration in the TUI is kinda clunky. It'd be better off in a file so it can be persisted and shared between sessions.

Always show collection path in footer

Right now it only shows the collection path in the footer after a reload (because it comes from the notification). It should always be visible on the screen.

Don't panic TUI when collection is invalid

If the collection is invalid when the TUI first loads, it should display it in a error modal instead of a panic. Basically it should behave the same as if the collection was invalid after a running reload, except that the error modal will take up the whole screen because there's nothing else to show.

Navigate request history

It should be possible to view all historical requests for a recipe, and switch between them. The data is already there, just need to figure out the UI.

Preview templated values

You should be able to toggle between rendering template strings as the raw string (e.g. {{host}}/get) and the rendered value (e.g. https://httpbin.org/get). Each rendered value should get some extra styling (e.g. a background highlight) to indicate it's a templated value.

Allow defining URL as separate `host` and `path` fields

The existing url field should still be supported, but adding two alternatives of host and path would cut down on boilerplate when making a bunch of recipes that hit the same host, because you could factor out host into a base recipe. This does introduce the need for a validation step though, to make sure eithee one or the other is defined.

feature may not be used on the stable release channel

Hi,

Cargo.toml states rust-version = "1.72.0" but, compiling slumber using Rust-1.73 yields the following:

   Compiling slumber v0.7.0 (/usr/pkgsrc/wip/slumber/work/slumber-0.7.0)
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:2:1
  |
2 | #![feature(associated_type_defaults)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:3:1
  |
3 | #![feature(iterator_try_collect)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:4:1
  |
4 | #![feature(lazy_cell)]
  | ^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:5:1
  |
5 | #![feature(trait_upcasting)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:6:1
  |
6 | #![feature(try_blocks)]
  | ^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:3:12
  |
3 | #![feature(iterator_try_collect)]
  |            ^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:4:12
  |
4 | #![feature(lazy_cell)]
  |            ^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `slumber` (bin "slumber") due to 7 previous errors
*** Error code 101

Stop.

So, what's the MSRV for this project?

Profile/recipe inheritance

Inheritance would be easier to use and more flexible than YAML anchors. Example:

base: &base
  headers:
    Accept: application/json

requests:
  - <<: *base
    id: get
    method: GET
    url: "{{host}}/get"
    headers:
      Authorization: username:password

^^ this example does not work, because the headers in the child overrides the parent, and the Accept header is lost. An example with built-in inheritance would be:

requests:
  - id: base
    hidden: true
    headers:
      Accept: application/json
  - id: get
    extends: base
    method: GET
    url: "{{host}}/get"
    headers:
      Authorization: username:password

We'd have to decide if we want to support multiple inheritance, and would also need to handle cycles so it would add the need for a validation step to collection parsing, which is annoying. Not sure how else to accomplish this though.

Allow highlighting text

Right now you can't highlight text, which means you can't copy. This is in iterm2 (haven't tested other terminals)

Remember some UI state when reloading

Certain UI state fields would be nice to persist after a collection reload:

  • Selected profile
  • Selected recipe
  • Selected pane
  • Selected tab (request/response panes)
  • Fullscreened pane

This will require some safety checks, because if the reload removed the selected recipe/profile we need to reset that value. The IDs should be persisted, not the index, so if something is reordered in a list it stays correct.

Make request history profile-specific

When switching profiles, it should switch between different requests. Chained requests should only fetch results from the matching profile (or maybe results from no profile as well?)

Initially selected recipe shows no request history

When starting the TUI, the first recipe selected doesn't show anything. Once you move up/down the list everything works fine, but without that triggering event it never loads anything from the repo.

Recursive templating?

Would recursive templating be helpful? It would be a pain to implement but it's possible so I want to make sure there's demand before I do it. It would enable cases like this:

profiles:
  - id: foo
    data:
      token: Bearer {{chains.token}}

chains:
  - id: token
    source: !file ./token.txt

Show contents of profile

When viewing the profile list, it should show the contents of each profile on the right, rather than request/response

State file in root of data directory is created if collection fails to load

If there's a collection parsing error, a default collection with an empty id is created. This means the database is created at ./data/state.sqlite (reduced from ./data//state.sqlite. Not sure the best way to handle this, but using an empty string as default state is not great. It should be more explicit about whether or not a collection is present. It would probably introduce a bunch of annoying checks in the view code, but that's the price of greatness 🤷

Insomnia migration improvements

The insomnia migration tool is half-baked, some things that need to be improved:

  • Support chained values
  • Handle base environment to merge into others
    • Ideally this would be written as an anchor in the yaml, idk if serde_yaml supports that

Other stuff too, add to this list as necessary

Add a subcommand to generate curl

Add a subcommand that generates a curl command to execute a request. Curl won't generally be helpful since you can run the request yourself, but might be nice for sharing or distributable scripts.

Use a different log file for each session

Each session should get a unique log file, for two reasons:

  • Simultaneous sessions won't fight each other
  • Repeated sessions won't overwrite old ones

Probably need some way to manage old files though so they don't get huge... I'm sure there's a library for managing this.

Trim trailing newline from header values

If you use a generated header value from a chain, it's common to have a trailing newline. This will fail the request build because it's not a valid header value. Transparently modifying user input is generally not a good idea, but in this case we know it's going to cause an initialization failure so we might as well fix it in a reasonable way by chopping the newline. Should also do some testing to see what other trailing/leading whitespace should be trimmed.

Also, give better error message for failed HTTP build (if possible).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.