* readability improvements and reduced indirection
* adds type for handleShowModifyCookieModal
* correctly types wrapperProps property, thereby fixing bug.
if you add `console.log({ previewHidden, propsOne: this.props.wrapperProps.activeWorkspaceMeta });` to the third line of `_renderPreview()` you'll see that `activeWorkspaceMeta` is indeed, sometimes, `undefined.
Also, there's no reason to use `await` on `this.setState`. I didn't find any more of these in the codebase, I just found this one.
* adds type for swaggerUiSpec
* undoes lifting props to state
almost always, this is done for performance reasons, but I removed it the app is working pretty quick-and-snappy for me without needing to introduced duplicated application state and keep track of it.
I went ahead and measured it before and after this commit (using performance.now):
before = [
1.93500000750646,
1.149999996414408,
0.9499999869149178,
0.9950000094249845,
0.8650000090710819,
1.560000004246831,
1.5699999930802733,
0.8450000023003668,
1.4550000196322799,
1.3299999991431832,
1.3050000125076622,
1.4099999971222132,
1.3099999923724681,
1.3100000214762986,
1.1999999987892807,
1.0099999781232327,
0.830000004498288,
1.2449999921955168,
1.2500000011641532,
1.4349999837577343,
]
after = [
2.9400000057648867,
2.449999999953434,
2.33499999740161,
2.2849999950267375,
1.7700000025797635,
1.8149999959859997,
2.1249999990686774,
1.9150000007357448,
2.074999996693805,
1.9899999897461385,
2.0200000144541264,
2.869999996619299,
2.1450000058393925,
2.33499999740161,
2.130000008037314,
2.119999990100041,
2.144999976735562,
2.130000008037314,
2.380000009201467,
2.8999999922234565,
]
> R.mean(before)
> 1.2480000004870817
> R.mean(after)
> 2.243749999080319
> R.median(before)
> 1.2775000068359077
> R.median(after)
> 2.137499992386438
So basically, considering a 16ms render rate (i.e. 60hz), 1ms saved by lifting props to state makes no difference in application performance.
This is committed separately so that if there's any reason we want to keep the prior implementation, we can just still do so.
* fix ts-expect-error
* removes useless await
see https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/await-thenable.md
We're not quite ready to have this rule on everywhere, but in this case I can see that it's correct to follow.
* add comment about magic number
and moves the assignment to the one place it's used
I opted not to make a ticket because we are recently running out of tickets and this seems to be a relatively small thing @reynolek please confirm this is the correct course of action.
* initialize ref to reflect reality (and include actual type)
* fixes root cause of error, inlines one-liners
the error with the type of `_handleInputColorChange` was due to `onChange` being the wrong prop to use (where `onChange` is the one we want).
* use onChange instead of onInput to access correct types
ultimately, since react's behavior diverged from the DOM behavior to match onInput, this should have no effect on any functionality since react assigns this event to `onChange` anyway. see https://github.com/facebook/react/blob/master/fixtures/attribute-behavior/src/attributes.js#L2089
* clears remaining ts-expect-errors in file
* updates fallback call per review feedback
* Add settings for color scheme detection and themes
Default light and dark themes can still be changed.
For now its studio-light and default for core, and studio-dark and studio-light for designer.
* Add color scheme type and supporting methods
The detection of dark scheme is based on the background color at the moment.
This seems to work pretty well, but is not an ideal solution.
I think themes should at least get to override this.
* Add support for choosing light and dark theme to settings
This adds a checkbox to the theme settings that determines whether we use the OS color scheme.
If we don't (default) everything stays the same as before.
If we do, themes are rendered in two groups. One for the light themes and one for the dark themes. They can be chosen independently. None of this overrides the default theme choice.
* Add padding to the theme settings tab
Themes are still aligned by adding negative margin.
A bit of a hack, open for suggestions.
* Update theme on OS color scheme change
* Replace usages of setTheme with applyColorScheme
This makes sure that we don't override the user's choice.
* Update packages/insomnia-app/app/plugins/misc.js
Co-authored-by: Opender Singh <opender94@gmail.com>
* Remove dark mode heuristic
* Remove unused button value
* Update theme settings design
* Update packages/insomnia-app/app/ui/components/settings/theme.js
Co-authored-by: Opender Singh <opender94@gmail.com>
* Update packages/insomnia-app/app/ui/components/settings/theme.js
Co-authored-by: Opender Singh <opender94@gmail.com>
* Replace object literal lookups
Do not use object literal lookups to make code more readable
* Remove unused parameter
* Disable default theme select when auto detection is enabled
* Fix imports after rebase
* Update packages/insomnia-app/app/ui/components/modals/settings-modal.js
Co-authored-by: Opender Singh <opender94@gmail.com>
* Update packages/insomnia-app/app/ui/components/modals/settings-modal.js
Co-authored-by: Opender Singh <opender94@gmail.com>
* Remove theme header
* Disable hover animation and border on disabled theme buttons
* Clean up double negation in css
Replace :not(:disabled) with :enabled. Not sure what I was thinking there.
* Update index.js
Co-authored-by: Opender Singh <opender94@gmail.com>
Co-authored-by: Opender Singh <opender.singh@konghq.com>
* Hide the active workspace when moving a folder (#2849)
* Change workspace to activeWorkspace for clarity
* Use map instead of flatMap for consistency
* feat(insomnia-components): add async-button
* feat: show error if parsing protofile fails during upload/add
* chore: flow is poop
* feat: use try-finally
