mirror of
https://github.com/galaxyproject/galaxy.git
synced 2026-09-21 22:06:53 +08:00
Merge pull request #15449 from dannon/prettier-targeting
Prettier targeting refinements
This commit is contained in:
Dannon
@@ -0,0 +1,14 @@
|
||||
# Standard ignores
|
||||
**/.git
|
||||
**/.svn
|
||||
**/.hg
|
||||
**/node_modules
|
||||
# Ignore the dist folder
|
||||
**/dist
|
||||
# We will always defer to package manager for formatting of package.json files.
|
||||
**/package.json
|
||||
# Skip formatting of explicitly included libs (to stay in sync with upstream, and they should go away eventually)
|
||||
src/libs
|
||||
# Don't reformat .json or .yml files included in the project
|
||||
*.json
|
||||
*.yml
|
||||
+2
-2
@@ -61,7 +61,7 @@ Or, with the package scripts from this `client` directory:
|
||||
|
||||
This will start up an extra client development server running on port 8081. Open
|
||||
your browser to `http://localhost:8081` (instead of the default 8080 that Galaxy
|
||||
would run on), and you should see Galaxy like normal. Except now, when you
|
||||
would run on), and you should see Galaxy like normal. Except now, when you
|
||||
change client code it'll automatically rebuild _and_ reload the relevant portion
|
||||
of the application for you. Lastly, if you are running Galaxy at a location
|
||||
other than the default, you can specify a different proxy target (in this
|
||||
@@ -119,7 +119,7 @@ framework.
|
||||
|
||||
For testing Vue components, we use the [Vue testing
|
||||
utils](https://vue-test-utils.vuejs.org/) to mount individual components in a
|
||||
test bed and check them for rendered features. Please use jest-based mocking
|
||||
test bed and check them for rendered features. Please use jest-based mocking
|
||||
for isolating test functionality.
|
||||
|
||||
A set of older qUnit tests also exist which will be phased-out as the code they
|
||||
|
||||
@@ -9,17 +9,17 @@ you access to the Galaxy.config, current user, and current user histories. Pleas
|
||||
retrieve your values, and bypass importing Galaxy altogether.
|
||||
|
||||
#### Sometimes you still need to update Vue from backbone as the legacy environment changes
|
||||
|
||||
There are definitely use-cases where the Backbone models update over time and we need to update some
|
||||
value inside Vue. Instead of importing backbone models directly into Vue components, try building a
|
||||
backbone event listener that updates some relevant Vuex store.
|
||||
|
||||
* [Keeping Vuex in Sync with
|
||||
Galaxy](https://github.com/galaxyproject/galaxy/blob/dev/client/src/store/syncVuexToGalaxy.js)
|
||||
- [Keeping Vuex in Sync with
|
||||
Galaxy](https://github.com/galaxyproject/galaxy/blob/dev/client/src/store/syncVuexToGalaxy.js)
|
||||
|
||||
These issues should disappear over time as the all of the old client is rebuilt in the new
|
||||
ecosystem.
|
||||
|
||||
|
||||
## Mount Functions
|
||||
|
||||
In what most people think of as a "standard" Vue application there would be only one place that Vue
|
||||
@@ -30,7 +30,6 @@ However, we are incrementally replacing old Backbone views, so in its current st
|
||||
several mounting functions for various components depending on where that component is intended to
|
||||
fit into the existing Backbone layouts.
|
||||
|
||||
|
||||
### Using the standard mount to pass in Galaxy variables as props
|
||||
|
||||
A standard mount function has been provided in src/utils. This mount function accepts a component
|
||||
@@ -46,28 +45,26 @@ import MyComponent from "components/MyComponent";
|
||||
import { mountVueComponent } from "utils/mountVueComponent";
|
||||
|
||||
const OldBackboneView = {
|
||||
|
||||
someInitMethodYouMake() {
|
||||
const Galaxy = getGalaxyInstance();
|
||||
const mounter = mountVueComponent(MyComponent);
|
||||
|
||||
// pass in required props
|
||||
const props = {
|
||||
|
||||
const props = {
|
||||
// Something peeled off the global galaxy
|
||||
somePropVal: Galaxy.someDealie,
|
||||
somePropVal: Galaxy.someDealie,
|
||||
|
||||
// ...or the current history
|
||||
name: Galaxy.currentHistory.name,
|
||||
|
||||
// or maybe from the backbone model for this view
|
||||
shoeSize: this.model.shoeSize
|
||||
shoeSize: this.model.shoeSize,
|
||||
};
|
||||
|
||||
// VM is a Vue instance.
|
||||
// this.$el is some jquery selection, first item is the actual DOM object
|
||||
const container = this.$el[0];
|
||||
const vm = mounter(props, container);
|
||||
}
|
||||
}
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
@@ -6,9 +6,9 @@ Using them effectively can make your code more reusable, decoupled, and easier t
|
||||
|
||||
**More about Composables:**
|
||||
|
||||
* [Composables Overview](https://vuejs.org/guide/reusability/composables.html)
|
||||
* [Composition API](https://vuejs.org/api/composition-api-setup.html)
|
||||
* [\<script setup\>](https://vuejs.org/api/sfc-script-setup.html)
|
||||
- [Composables Overview](https://vuejs.org/guide/reusability/composables.html)
|
||||
- [Composition API](https://vuejs.org/api/composition-api-setup.html)
|
||||
- [\<script setup\>](https://vuejs.org/api/sfc-script-setup.html)
|
||||
|
||||
## Using Composables in the Composition API
|
||||
|
||||
@@ -36,8 +36,8 @@ export default {
|
||||
setup() {
|
||||
const { currentUser } = useCurrentUser();
|
||||
return { currentUser };
|
||||
}
|
||||
}
|
||||
},
|
||||
};
|
||||
</script>
|
||||
```
|
||||
|
||||
@@ -79,7 +79,7 @@ import { useCurrentUser } from "composables/user";
|
||||
|
||||
jest.mock("composables/user");
|
||||
useCurrentUser.mockReturnValue({
|
||||
currentUser: {}
|
||||
currentUser: {},
|
||||
});
|
||||
```
|
||||
|
||||
@@ -95,11 +95,7 @@ Usage:
|
||||
<script setup>
|
||||
import { useFilterObjectArray } from "composables/utils/filter";
|
||||
|
||||
const filteredArray = useFilterObjectArray(
|
||||
someReactiveArray,
|
||||
searchValue,
|
||||
["name", "description"]
|
||||
);
|
||||
const filteredArray = useFilterObjectArray(someReactiveArray, searchValue, ["name", "description"]);
|
||||
</script>
|
||||
```
|
||||
|
||||
|
||||
+14
-14
@@ -6,23 +6,23 @@ Heading Levels are used by screen readers, and other software, to get a rough id
|
||||
|
||||
## Heading Level best practices
|
||||
|
||||
- Make sure every route has exactly one `<h1>` element, which best describes the content of the current page.
|
||||
- Make sure every route has exactly one `<h1>` element, which best describes the content of the current page.
|
||||
|
||||
- When increasing a heading level, do not skip Levels.
|
||||
- When increasing a heading level, do not skip Levels.
|
||||
|
||||
- Do not use a headings level to determine it's size. Use one of the heading utility classes (e.g. `h-lg`) instead.
|
||||
- Do not use a headings level to determine it's size. Use one of the heading utility classes (e.g. `h-lg`) instead.
|
||||
|
||||
- Do not use a heading tag to make a non-heading text large. Use a heading utility class on a `<span>` instead.
|
||||
- Do not use a heading tag to make a non-heading text large. Use a heading utility class on a `<span>` instead.
|
||||
|
||||
## Sizing Headings
|
||||
|
||||
There are several utility classes which size headings:
|
||||
|
||||
- `h-xl` - Extra large headings
|
||||
- `h-lg` - Large headings (most main headings should have this size)
|
||||
- `h-md` - Medium headings
|
||||
- `h-sm` - Small headings (many sub-headings have this size)
|
||||
- `h-text` - Text sized headings
|
||||
- `h-xl` - Extra large headings
|
||||
- `h-lg` - Large headings (most main headings should have this size)
|
||||
- `h-md` - Medium headings
|
||||
- `h-sm` - Small headings (many sub-headings have this size)
|
||||
- `h-text` - Text sized headings
|
||||
|
||||
Galaxy uses `h-lg` for most top-level (`<h1>`) headings.
|
||||
|
||||
@@ -45,8 +45,8 @@ Set the headings level, by setting aa `h1 ... h6` prop:
|
||||
|
||||
Following properties allow for further styling the component:
|
||||
|
||||
- `size=["xl", "lg", "md", "sm", "text"]` - sets the headings size class
|
||||
- `bold` - makes a heading bold
|
||||
- `inline` - displays the heading inline
|
||||
- `separator` - draws a separating line, to better distinguish sections
|
||||
- `icon="..."` - adds a font-awesome icon decoration to the left of the heading. Make sure to also load the icon with `library.add(...)`.
|
||||
- `size=["xl", "lg", "md", "sm", "text"]` - sets the headings size class
|
||||
- `bold` - makes a heading bold
|
||||
- `inline` - displays the heading inline
|
||||
- `separator` - draws a separating line, to better distinguish sections
|
||||
- `icon="..."` - adds a font-awesome icon decoration to the left of the heading. Make sure to also load the icon with `library.add(...)`.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
Did you know, jQuery is old enough to drive? It's old enough to get a driver's license. jQuery is a
|
||||
tool that was built to deal with inconsistencies in browsers that NO LONGER EXIST. In a couple
|
||||
years, jQuery will be voting, drinking, and capable of being tried as an adult.
|
||||
years, jQuery will be voting, drinking, and capable of being tried as an adult.
|
||||
|
||||
If you think you need jQuery, you are mistaken. Please seek help from somebody in the wg-ui-ux
|
||||
workgroup. There is nothing jQuery can provide you that isn't already part of vanilla javascript or
|
||||
@@ -14,5 +14,6 @@ One of our most important goals in redesigning Galaxy is the complete eliminatio
|
||||
from our source, along with all its invasive plugins.
|
||||
|
||||
### References
|
||||
* [You Don't Need jQuery](https://github.com/nefe/You-Dont-Need-jQuery)
|
||||
* [document.querySelector](https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector)
|
||||
|
||||
- [You Don't Need jQuery](https://github.com/nefe/You-Dont-Need-jQuery)
|
||||
- [document.querySelector](https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector)
|
||||
|
||||
@@ -22,34 +22,27 @@ component we previously made, but you are free to putput whatever you want in th
|
||||
doodad and saveDoddad properties as desired, as well as any other local data with the only
|
||||
restriction that Vue needs a single root element in which to render.
|
||||
|
||||
|
||||
## The Renderer
|
||||
|
||||
```html static
|
||||
<!-- DoodadEditor.vue, a simple "rendering" component -->
|
||||
|
||||
<template>
|
||||
<AutoComplete
|
||||
:options="options"
|
||||
:value="doodad.category"
|
||||
@select="saveCategory"
|
||||
/>
|
||||
<AutoComplete :options="options" :value="doodad.category" @select="saveCategory" />
|
||||
</template>
|
||||
|
||||
<script>
|
||||
|
||||
export default {
|
||||
props: {
|
||||
doodad: { type: Object, required: true },
|
||||
options: { type: Array, required: true },
|
||||
},
|
||||
methods: {
|
||||
saveCategory(newCategory) {
|
||||
this.$emit('update:doodad', { ...this.doodad, category: newCategory });
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
export default {
|
||||
props: {
|
||||
doodad: { type: Object, required: true },
|
||||
options: { type: Array, required: true },
|
||||
},
|
||||
methods: {
|
||||
saveCategory(newCategory) {
|
||||
this.$emit("update:doodad", { ...this.doodad, category: newCategory });
|
||||
},
|
||||
},
|
||||
};
|
||||
</script>
|
||||
```
|
||||
|
||||
@@ -66,7 +59,6 @@ binds](https://vuejs.org/v2/guide/components-custom-events.html#sync-Modifier)).
|
||||
Whatever happens to that new object is somebody else's job. As soon as you tie the data management
|
||||
to the rendering, the re-usability of your components craters.
|
||||
|
||||
|
||||
## The Provider
|
||||
|
||||
As the opposite of the rendering component, a provider or renderless component, is pure logic. It
|
||||
@@ -76,7 +68,6 @@ functionality available in Vue. Some others are [Mixins](https://vuejs.org/v2/gu
|
||||
[Provide/Inject](https://v3.vuejs.org/guide/component-provide-inject.html) and (in Vue3) [the
|
||||
composition API](https://v3.vuejs.org/guide/composition-api-introduction.html).
|
||||
|
||||
|
||||
```js static
|
||||
// DoodadProvider.js
|
||||
|
||||
@@ -134,7 +125,7 @@ mandatory markup, just one big empty slot.
|
||||
// Testing a renderless component
|
||||
|
||||
import { shallowMount } from "@vue/test-utils";
|
||||
import { getLocalVue, waitForLifecyleEvent } from "tests/jest/helpers"
|
||||
import { getLocalVue, waitForLifecyleEvent } from "tests/jest/helpers";
|
||||
import DoodadProvider from "./DoodadProvider";
|
||||
|
||||
describe("A renderless component", () => {
|
||||
@@ -157,12 +148,12 @@ describe("A renderless component", () => {
|
||||
// component. This is often good enough for waiting for
|
||||
// an initial ajax load to finish, for example
|
||||
await waitForLifecyleEvent(wrapper.vm, "updated");
|
||||
})
|
||||
});
|
||||
|
||||
test("someProp", () => {
|
||||
const { someProp } = slotProps;
|
||||
expect(someProp).toExist();
|
||||
// ...more tests
|
||||
})
|
||||
})
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
@@ -5,7 +5,7 @@ I'm not talking about how webpack turns it into a rendering function. That's obv
|
||||
I mean conceptually, props come in (like arguments) and events go out (like the return statements).
|
||||
A component is a fancy kind of function that can keep emitting results and accept changing inputs
|
||||
over time. In truth it more closely resembles an Observable, but an observable is ALSO a slightly
|
||||
fancier kind of function.
|
||||
fancier kind of function.
|
||||
|
||||
If you just think of a component as thing that takes input props and emits output events you're well
|
||||
on your way to using them well.
|
||||
@@ -19,22 +19,22 @@ problems of the old imperative class-based legacy code.
|
||||
New vue programmers are ok at handing props to components, but they rarely use events effectively
|
||||
(at first). As a result they end up using a lot of global state, a million little data props and
|
||||
relying on imperfect globalized tools like Vuex or other imported dependencies for every little
|
||||
variable.
|
||||
variable.
|
||||
|
||||
Vuex definitely has its uses, but not as many as you might expect given the way it is
|
||||
overly-emphasized in common tutorials. It's easy to walk away from an "Intro to Vue" video with the
|
||||
idea that all data must live in Vuex all the time. That's a really undesirable situation.
|
||||
idea that all data must live in Vuex all the time. That's a really undesirable situation.
|
||||
|
||||
Although vuex is a well-organized (many would say over-organized) state machine, it is important
|
||||
to remember that it is still a kind of global injection and deserves to be considered as such.
|
||||
|
||||
* [Should I Store This Data in
|
||||
Vuex](https://markus.oberlehner.net/blog/should-i-store-this-data-in-vuex/)
|
||||
* [Vuex getters are great, but don’t overuse
|
||||
them](https://codeburst.io/vuex-getters-are-great-but-dont-overuse-them-9c946689b414)
|
||||
- [Should I Store This Data in
|
||||
Vuex](https://markus.oberlehner.net/blog/should-i-store-this-data-in-vuex/)
|
||||
- [Vuex getters are great, but don’t overuse
|
||||
them](https://codeburst.io/vuex-getters-are-great-but-dont-overuse-them-9c946689b414)
|
||||
|
||||
Data persistence should be something that happens near the top of your component tree, not down in
|
||||
the guts.
|
||||
the guts.
|
||||
|
||||
Your first thought with a component should be: "How can I offload the handling of the results of
|
||||
this component to my caller?" The answer is usually going to be events. A component that simply
|
||||
@@ -46,7 +46,6 @@ global state to operate.
|
||||
They're just fancy shorthands for a prop / event handler combination. They are fundamentally no
|
||||
different from props and events, but the syntax is important to understand.
|
||||
|
||||
|
||||
### Think carefully about what should really be in "data".
|
||||
|
||||
Most of good component design boils down to answering the following question: What do I want to put
|
||||
|
||||
@@ -44,7 +44,7 @@ const myFunction = (param) => {
|
||||
};
|
||||
|
||||
// anonymous functions
|
||||
const myFunction = function(param) {
|
||||
const myFunction = function (param) {
|
||||
//do stuff
|
||||
};
|
||||
```
|
||||
@@ -84,10 +84,9 @@ When possible, use arrow functions instead.
|
||||
> export function myFunction(parameter) {
|
||||
> const addOne = (value) => {
|
||||
> return value + 1;
|
||||
> }
|
||||
> };
|
||||
> // do more stuff...
|
||||
> }
|
||||
>
|
||||
> ```
|
||||
>
|
||||
> **Don't**
|
||||
@@ -96,12 +95,11 @@ When possible, use arrow functions instead.
|
||||
> // in myModules.js
|
||||
>
|
||||
> export const myFunction = (parameter) => {
|
||||
> const addOne = function(value) {
|
||||
> const addOne = function (value) {
|
||||
> return value + 1;
|
||||
> }
|
||||
> };
|
||||
> // do more stuff...
|
||||
> }
|
||||
>
|
||||
> };
|
||||
> ```
|
||||
|
||||
## HTML Multi-Line Layout
|
||||
@@ -115,9 +113,7 @@ Prettier tries to respect whitespace when formatting your HTML templates, even w
|
||||
Might get turned into:
|
||||
|
||||
```vue
|
||||
<b-button class="danger-button mb-4" variant="danger" @click="onDangerButtonClick"
|
||||
>A very Long Button Text</b-button
|
||||
>
|
||||
<b-button class="danger-button mb-4" variant="danger" @click="onDangerButtonClick">A very Long Button Text</b-button>
|
||||
```
|
||||
|
||||
Notice the strange positioning of the `>` brackets.
|
||||
@@ -277,7 +273,7 @@ Do not add space between elements connected by conditionals.
|
||||
> <span v-if="conditional">
|
||||
> condition met
|
||||
> </span>
|
||||
>
|
||||
>
|
||||
> <span v-else>
|
||||
> condition not met
|
||||
> </span>
|
||||
@@ -293,7 +289,7 @@ Add space between non-connected elements.
|
||||
> <span>
|
||||
> First span.
|
||||
> </span>
|
||||
>
|
||||
>
|
||||
> <span>
|
||||
> Second span.
|
||||
> </span>
|
||||
@@ -325,7 +321,7 @@ Add space between logical blocks of elements.
|
||||
> <span v-else>
|
||||
> condition 1 not met
|
||||
> </span>
|
||||
>
|
||||
>
|
||||
> <span v-if="otherConditional">
|
||||
> condition 2 met
|
||||
> </span>
|
||||
|
||||
@@ -9,7 +9,7 @@ code updates its test extensions again.
|
||||
|
||||
#### To debug a single Jest test:
|
||||
|
||||
1. Open a jest test (a file that ends with *.test.js)
|
||||
1. Open a jest test (a file that ends with \*.test.js)
|
||||
|
||||
1. Make sure the test file is selected, especially if you have multiple files open. This process
|
||||
will fail confusingly and without obvious error if you have not launched the debugger with the
|
||||
@@ -34,8 +34,6 @@ code updates its test extensions again.
|
||||
variables near your breakpoint and see their values in the "Variables" section of the Run and
|
||||
Debug pane.
|
||||
|
||||
|
||||
|
||||
```json
|
||||
// sample launch.json
|
||||
{
|
||||
@@ -45,16 +43,16 @@ code updates its test extensions again.
|
||||
"type": "node",
|
||||
"name": "debug selected jest test",
|
||||
"request": "launch",
|
||||
|
||||
|
||||
// launches version of jest from inside the node_modules
|
||||
// this means you need to have run yarn first
|
||||
"program": "${workspaceFolder}/client/node_modules/jest/bin/jest",
|
||||
"args": [
|
||||
// Alias -i.
|
||||
// Alias -i.
|
||||
// Normally jest opens up a bunch of workers to run all your tests faster
|
||||
// but we don't want that right now.
|
||||
"--runInBand",
|
||||
|
||||
|
||||
// finds jest config
|
||||
"--config",
|
||||
"${workspaceFolder}/client/tests/jest/jest.config.js",
|
||||
@@ -68,9 +66,8 @@ code updates its test extensions again.
|
||||
"console": "integratedTerminal",
|
||||
|
||||
// allows you to place breakpoints right in vscode's gutter
|
||||
"disableOptimisticBPs": true,
|
||||
},
|
||||
|
||||
"disableOptimisticBPs": true
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
@@ -1,20 +1,18 @@
|
||||
|
||||
[Galaxy uses Jest](https://jestjs.io/) for its client-side unit testing
|
||||
framework.
|
||||
|
||||
For testing Vue components, we use the [Vue testing
|
||||
utils](https://vue-test-utils.vuejs.org/) to mount individual components in a
|
||||
test bed and check them for rendered features. Please use jest-based mocking
|
||||
test bed and check them for rendered features. Please use jest-based mocking
|
||||
for isolating test functionality.
|
||||
|
||||
|
||||
### Specific test scenarios & examples
|
||||
|
||||
* [Mocking an imported
|
||||
dependency](https://github.com/galaxyproject/galaxy/blob/dev/client/src/components/Tags/tagService.test.js)
|
||||
* [Testing async
|
||||
operations](https://github.com/galaxyproject/galaxy/blob/dev/client/src/components/Tags/tagService.test.js)
|
||||
* [Testing a Vue component for expected rendering
|
||||
output](https://github.com/galaxyproject/galaxy/blob/dev/client/src/components/Tags/StatelessTags.test.js)
|
||||
* [Firing an event against a shallow mounted vue
|
||||
component](https://github.com/galaxyproject/galaxy/blob/dev/client/src/components/Tags/StatelessTags.test.js)
|
||||
- [Mocking an imported
|
||||
dependency](https://github.com/galaxyproject/galaxy/blob/dev/client/src/components/Tags/tagService.test.js)
|
||||
- [Testing async
|
||||
operations](https://github.com/galaxyproject/galaxy/blob/dev/client/src/components/Tags/tagService.test.js)
|
||||
- [Testing a Vue component for expected rendering
|
||||
output](https://github.com/galaxyproject/galaxy/blob/dev/client/src/components/Tags/StatelessTags.test.js)
|
||||
- [Firing an event against a shallow mounted vue
|
||||
component](https://github.com/galaxyproject/galaxy/blob/dev/client/src/components/Tags/StatelessTags.test.js)
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
Part of making good code is making that code easy to test.
|
||||
Part of making good code is making that code easy to test.
|
||||
|
||||
### Implement logic in pure functions when possible
|
||||
|
||||
@@ -10,14 +10,13 @@ There is almost definitely no such thing as a well-written 1000 line function.
|
||||
Most of whatever happened in that thing was probably deterministic and can be
|
||||
broken up into easily testable chunks.
|
||||
|
||||
|
||||
### Wrap native browser resources in a function so they can be easily mocked
|
||||
|
||||
If your javascript needs to talk to the window object, or navigator, etc. wrap
|
||||
that in a function call so that it can be easily mocked during testing.
|
||||
|
||||
|
||||
#### Your Module
|
||||
|
||||
```js static
|
||||
// myModule.js
|
||||
|
||||
@@ -35,6 +34,7 @@ export function theThingYouReallyCareAbout() {
|
||||
```
|
||||
|
||||
#### Your test file
|
||||
|
||||
```js static
|
||||
// myModule.test.js
|
||||
import { theThingYouReallyCareAbout, redirectTo } from "./myModule";
|
||||
|
||||
@@ -2,14 +2,13 @@
|
||||
|
||||
Please remember that these tests are not _for_ you. They're for the people who
|
||||
come after you. It will be a lot easier to modify, repair and upgrade your code
|
||||
if they can figure out what you were originally hoping to accomplish. Try to
|
||||
if they can figure out what you were originally hoping to accomplish. Try to
|
||||
use as detailed 'expect' statements as possible -- overuse of 'toBeTruthy()'
|
||||
for example, can hide the intent of your test.
|
||||
|
||||
Add a couple of comments. Use variable names that mean something. Nobody's
|
||||
Add a couple of comments. Use variable names that mean something. Nobody's
|
||||
code is as self-documenting as they believe it to be.
|
||||
|
||||
|
||||
### Only test the public API that you define
|
||||
|
||||
Internal implementations come and go with library upgrades and new tech. But
|
||||
@@ -20,17 +19,16 @@ Separate your concerns and identify the developer-facing methods and functions
|
||||
you expect them to use. Test THOSE. Everything else should probably be
|
||||
considered an implementation detail.
|
||||
|
||||
The other side of the same coin is to test *only* the unit in question. If your
|
||||
The other side of the same coin is to test _only_ the unit in question. If your
|
||||
component has a model that uses a service that touches Vuex, which then uses
|
||||
Axios to fetch some data -- don't test all that at once. Break things apart and
|
||||
mock functionality to isolate testing to units. End to end testing is a
|
||||
Axios to fetch some data -- don't test all that at once. Break things apart and
|
||||
mock functionality to isolate testing to units. End to end testing is a
|
||||
separate thing that shouldn't be attempted using spec tests in Jest.
|
||||
|
||||
Assume nobody cares _how_ your code works, we just need to know that the public
|
||||
API you designed _does_ work. If performance problems or new tech necessitate a
|
||||
re-write, these tests become a guide for the next implementation.
|
||||
|
||||
|
||||
### Writing a test file
|
||||
|
||||
Jest will try to test any file ending in "\*.test.js". Please place your test
|
||||
@@ -65,9 +63,7 @@ describe("some module you wrote", () => {
|
||||
});
|
||||
```
|
||||
|
||||
|
||||
### Check out the Jest helper functions
|
||||
|
||||
We have created some [common helpers for common testing
|
||||
scenarios](https://github.com/galaxyproject/galaxy/blob/dev/client/tests/jest/helpers.js).
|
||||
|
||||
scenarios](https://github.com/galaxyproject/galaxy/blob/dev/client/tests/jest/helpers.js).
|
||||
|
||||
+2
-2
@@ -123,8 +123,8 @@
|
||||
"webpack-production-maps": "GXY_BUILD_SOURCEMAPS=1 NODE_ENV=production webpack",
|
||||
"gulp": "gulp",
|
||||
"stage-build": "cpy 'dist/*' '../static/dist' && (git rev-parse HEAD 2>/dev/null || echo '') >../static/client_build_hash.txt",
|
||||
"format": "prettier --write 'src/style/scss/**/*.scss' 'src/**/{*.ts,*.js,*.vue}' 'tests/jest/standalone/{*.ts,*.js}' '!src/libs/**'",
|
||||
"format-check": "prettier --check 'src/style/scss/**/*.scss' 'src/**/{*.js,*.vue}' 'tests/jest/standalone/{*.ts,*.js}' '!src/libs/**'",
|
||||
"format": "prettier --write .",
|
||||
"format-check": "prettier --check .",
|
||||
"prettier": "yarn run format",
|
||||
"test": "yarn run qunit && yarn run jest",
|
||||
"jest": "jest --config tests/jest/jest.config.js",
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
module.exports = {
|
||||
tabWidth: 4,
|
||||
printWidth: 120,
|
||||
bracketSameLine: true
|
||||
bracketSameLine: true,
|
||||
};
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
```js
|
||||
<div v-for="variant in [ 'success', 'info', 'warning', 'error' ]">
|
||||
<Alert v-bind:variant="variant">A {{variant}} message</Alert>
|
||||
<Alert v-bind:variant="variant">A {{ variant }} message</Alert>
|
||||
</div>
|
||||
```
|
||||
|
||||
|
||||
@@ -1,13 +1,12 @@
|
||||
### History Panel Component Tree
|
||||
|
||||
This is not intended to be a complete listing, but a general idea of how the components are intended
|
||||
to interact with each other.
|
||||
|
||||
```html static
|
||||
<Index :history="history">
|
||||
|
||||
<!-- if main history selected -->
|
||||
<CurrentHistory :history="history">
|
||||
|
||||
<!-- Data providers do the heavy-lifting of mixing params, history, and
|
||||
scroll position to deliver the content for the scroller -->
|
||||
<StoreProvider>
|
||||
@@ -18,7 +17,7 @@ to interact with each other.
|
||||
|
||||
<!-- Uses a virtual scroller plugin to render all ContentItems and throttles the scrolling pace by limiting
|
||||
the frequency and magnitude of offset changes. -->
|
||||
<Listing>
|
||||
<listing>
|
||||
|
||||
<!-- The ContentItem renders a row in the list, showing the title, some attributes,
|
||||
and basic operation buttons such as display and edit for either a dataset or a collection.
|
||||
@@ -40,11 +39,11 @@ to interact with each other.
|
||||
<CollectionOperations />
|
||||
|
||||
<!-- As above, the same virtual scroller and ContentItem component is being used to render the elements. -->
|
||||
<Listing>
|
||||
<listing>
|
||||
(<ContentItem />)
|
||||
<DatasetDetails />
|
||||
</Listing>
|
||||
</StoreProvider>
|
||||
</CurrentCollection>
|
||||
</Index>
|
||||
```
|
||||
```
|
||||
|
||||
@@ -3,15 +3,15 @@ th:focus {
|
||||
}
|
||||
|
||||
.pagination-input-field {
|
||||
max-width: 60px
|
||||
max-width: 60px;
|
||||
}
|
||||
|
||||
.pagination-total-pages-text {
|
||||
margin-left: .25rem;
|
||||
margin-left: 0.25rem;
|
||||
}
|
||||
|
||||
.more-text-btn {
|
||||
margin-left: .25rem;
|
||||
margin-left: 0.25rem;
|
||||
font-size: 60%;
|
||||
color: grey;
|
||||
}
|
||||
@@ -20,7 +20,6 @@ th:focus {
|
||||
width: 40rem;
|
||||
}
|
||||
|
||||
|
||||
.empty-folder-message {
|
||||
text-align: center;
|
||||
}
|
||||
@@ -34,5 +33,5 @@ th:focus {
|
||||
}
|
||||
|
||||
.lib-btn {
|
||||
margin-bottom: 2%
|
||||
margin-bottom: 2%;
|
||||
}
|
||||
|
||||
@@ -5,6 +5,6 @@ export default {
|
||||
caching: {
|
||||
adapter: "memory",
|
||||
revs_limit: 1,
|
||||
pageSize: 50
|
||||
}
|
||||
}
|
||||
pageSize: 50,
|
||||
},
|
||||
};
|
||||
|
||||
@@ -8,4 +8,4 @@ export class TracksterUI extends Backbone.Model {
|
||||
initialize(baseURL) {
|
||||
this.baseURL = baseURL;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
module.exports = {
|
||||
process: content => { return { code: "module.exports = " + JSON.stringify(content)}}
|
||||
process: (content) => {
|
||||
return { code: "module.exports = " + JSON.stringify(content) };
|
||||
},
|
||||
};
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
import "@testing-library/jest-dom";
|
||||
import Vue from 'vue';
|
||||
import Vue from "vue";
|
||||
|
||||
// Set Vue to suppress production / devtools / etc. warnings
|
||||
Vue.config.productionTip = false;
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
const transformer = require("yaml-jest").default
|
||||
const transformer = require("yaml-jest").default;
|
||||
|
||||
const newTransformer = {
|
||||
...transformer,
|
||||
process: function (...params) {
|
||||
return {
|
||||
code: transformer?.process(...params),
|
||||
map: null,
|
||||
}
|
||||
},
|
||||
}
|
||||
...transformer,
|
||||
process: function (...params) {
|
||||
return {
|
||||
code: transformer?.process(...params),
|
||||
map: null,
|
||||
};
|
||||
},
|
||||
};
|
||||
|
||||
module.exports = newTransformer
|
||||
module.exports = newTransformer;
|
||||
|
||||
@@ -19,23 +19,23 @@ var datasets1 = [
|
||||
];
|
||||
|
||||
var datasets2 = [
|
||||
{ name: "DP134_1_FS_PSII_FSB_42C_A10.1.fastq", state: STATES.OK},
|
||||
{ name: "DP134_1_FS_PSII_FSB_42C_A10.2.fastq", state: STATES.OK}
|
||||
]
|
||||
{ name: "DP134_1_FS_PSII_FSB_42C_A10.1.fastq", state: STATES.OK },
|
||||
{ name: "DP134_1_FS_PSII_FSB_42C_A10.2.fastq", state: STATES.OK },
|
||||
];
|
||||
|
||||
var datasets3 = [
|
||||
{name: "UII_moo_1.1.fastq", state: STATES.OK},
|
||||
{name: "UII_moo_1.2.fastq", state: STATES.OK}
|
||||
]
|
||||
{ name: "UII_moo_1.1.fastq", state: STATES.OK },
|
||||
{ name: "UII_moo_1.2.fastq", state: STATES.OK },
|
||||
];
|
||||
|
||||
var datasets4= [
|
||||
var datasets4 = [
|
||||
{ name: "SET1-01_R1.fastq", state: STATES.OK },
|
||||
{ name: "SET1-01_R2.fastq", state: STATES.OK },
|
||||
{ name: "SET1-02_R1.fastq", state: STATES.OK },
|
||||
{ name: "SET1-02_R2.fastq", state: STATES.OK },
|
||||
{ name: "SET1-03_R1.fastq", state: STATES.OK },
|
||||
{ name: "SET1-03_R2.fastq", state: STATES.OK },
|
||||
]
|
||||
];
|
||||
|
||||
var datasets1CreateRequestJSON = {
|
||||
type: "dataset_collection",
|
||||
@@ -171,5 +171,5 @@ export default {
|
||||
_1requestJSON: datasets1CreateRequestJSON,
|
||||
_2: datasets2,
|
||||
_3: datasets3,
|
||||
_4: datasets4
|
||||
_4: datasets4,
|
||||
};
|
||||
|
||||
Vendored
+2
-2
@@ -1,4 +1,4 @@
|
||||
// Webpack-injected globals.
|
||||
declare const __webpack_public_path__:string;
|
||||
declare const __webpack_public_path__: string;
|
||||
declare const __buildTimestamp__: string;
|
||||
declare const __license__: string;
|
||||
declare const __license__: string;
|
||||
|
||||
Vendored
+2
-2
@@ -1,4 +1,4 @@
|
||||
declare module "*.vue" {
|
||||
import Vue from "vue";
|
||||
export default Vue;
|
||||
import Vue from "vue";
|
||||
export default Vue;
|
||||
}
|
||||
|
||||
Vendored
+3
-3
@@ -1,4 +1,4 @@
|
||||
declare module '*.yml' {
|
||||
const data: any
|
||||
export default data
|
||||
declare module "*.yml" {
|
||||
const data: any;
|
||||
export default data;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user