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

Feat/auto browser and bad query fallback #9

Merged
merged 4 commits into from
Jun 17, 2024

Conversation

Kinfe123
Copy link
Contributor

This change include

  • first , idk if this is something to add but i feel it some of peeps might need it but personally i dont use it a lot which is authomatically opening of browser (default) when we spin up the backend rust server - since it is not allowing me to run mutliple port if 3030 is already in use.. i just hard coded the port which the browser opens
  • second - i have added the error message fallback like the image below for those that returns a error from backend . but this can be to have a stack trace to be displayed instead of blindly letting them know that something went wrong like ,something beyond syntax highlighting.
    image

@Kinfe123 Kinfe123 changed the title Feat/auto browser and query fallback Feat/auto browser and bad query fallback Jun 17, 2024
@frectonz
Copy link
Owner

I like the automatically opening the URL thing, but i don't like the "No such resource returned ..." thing, i prefer the skeleton. If you remove the that i will merge this PR.

@Kinfe123
Copy link
Contributor Author

Kinfe123 commented Jun 17, 2024

do you think skeleton would make sense for the users who aint know whether their query fails or not.. or we can stop the loading skeleon if the query fails to do so.

@frectonz
Copy link
Owner

frectonz commented Jun 17, 2024

Ok yeah, we should do this

  • show the loading skeleton, in the loading state
  • show nothing, in the error state

Since i want people to directly type in their queries and have the data fetched automatically, i don't want them to be bombarded with a "No such resource error".

@Kinfe123
Copy link
Contributor Author

Kinfe123 commented Jun 17, 2024

yeah we can handle that by debouncing but yeah it is better to return a nothing.

@frectonz
Copy link
Owner

Yeah but don't add debouncing. I want querying to feel extremely fast, deboucing will just add a delay. Since people are running the server on their own local machine, we don't care about how many times they hit the /query route. Debouncing would have made sense if we were calling an external API.

@Kinfe123
Copy link
Contributor Author

hmmm....makes sense , it is fixed by now

@frectonz frectonz merged commit f45da6e into frectonz:main Jun 17, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants