text:
Question about the lemma 1.6 and code implementation

Hi. In your paper the lemma 1.6 is talking about the distribution of X and Y=sin(pi/2*X). We have known that the output of linear layer is in normal distribution if taking specific initialization method uniform(-c,c). However, in your code, the activation is just torch.sin(x) not torch.sin(pi/2 * x). Is there something I missed?

Hi. In your paper the lemma 1.6 is talking about the distribution of X and Y=sin(pi/2*X). We have known that the output of linear layer is in normal distribution if taking specific initialization method uniform(-c,c). However, in your code, the activation is just torch.sin(x) not torch.sin(pi/2 * x). Is there something I missed?

Same question, do you have any idea now?

repo: vsitzmann/siren


text:
Incorrect handling of '\a'

Poedit 3.0.1 does not correctly handle the escape sequence '\a'. Steps to illustrate it:

Save the following as a .po file

msgid ""
msgstr ""
"Project-Id-Version: \n"
"POT-Creation-Date: \n"
"PO-Revision-Date: \n"
"Last-Translator: Someone <someone@example.com>\n"
"Language-Team: \n"
"Language: zh_CN\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"X-Generator: Poedit 3.0.1\n"

msgid "\\a"
msgstr ""

Open the file with poedit. The source text is shown as '\a'. Input '\a' in the translated text box, and save the file. You will find that the translated text is '\007' in the upper part of the window. This is inconsistent with the way poedit displays source text. And if you open the saved file with a text editor, the msgstr will be "\a" (should be "\a").
If you input '\a' in the translated text box, and save the file, the result will be correct, but if you reopen the file with poedit, the translated text will be shown as '\a' again, and if you append something to the translated text and save the file, you will get a "\a" in msgstr again.

What is "upper part of the window"?
What is "correct result" in your view and why do you think showing as '\a' is wrong (when you previously complained about not being that)?

What is "upper part of the window"?

The part that shows a summary of the strings, one string per line.

What is "correct result" in your view and why do you think showing as '\a' is wrong (when you previously complained about not being that)?

I edited the original post to add missed markdown escapes. Maybe there was some misunderstanding caused by it, so please re-read the original post, sorry :-)
The correct result in my view is, if you input '\a' in the translated text and save the file, the text shown in poedit should be '\a', but the msgstr should be "\\a" in a plain text editor. Both results are to be consistent with the way poedit displays the source text "\\a".
And if you input "\\a" in the translated text and save and re-open the file, the translated text shown should still be "\\a", of course.

source: gharchive/issue

authors: cloudfish vslavik

repo: vslavik/poedit

license: MIT

license_type: permissive

license_source: github-api


text:
Added QLayout

Project URL
https://github.com/josejuanqm/QLayout
Description
Added QLayout Package to the Layout category
Checklist

[x ] Only one project/change is in this pull request
[x ] Addition in chronological order (bottom of category)
[x ] Supports iOS 9 / tvOS 10 or later
[ x] Supports Swift 3 or later
[x ] Has a commit from less than 2 years ago
[x ] Has a clear README in English

          1 Warning

:warning:
Found 3 link issues, a project collaborator will take care of these, thanks :)

Link issues by awesome_bot

Line
Status
Link

2197
404
https://github.com/rob-nash/CollapsableTable

2217
404
https://github.com/rob-nash/PageFeedControl

2256
404
https://github.com/rob-nash/CollapsibleTable

  Generated by :no_entry_sign: Danger

@josejuanqm : Thanks for the contribution. @aaronjsutton and @lukecrum Thanks guys for approving.

Thank you everyone!

source: gharchive/pull-request

authors: arasu01 danger-awesome-ios josejuanqm

repo: vsouza/awesome-ios


text:
GeoLocation not supported via API

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Solved it here https://github.com/vtemian/buffpy/pull/22

@vtemian vtemian Now that Buffer.com is sunsetting their API, any plans of unofficial API ?

Hmm....sadly no. I'll do only small maintenance tasks for it and mainly that's it.
If you want to fork it and continue working on it, please do.

repo: vtemian/buffpy

license: mit

license_source: bigquery


text:
When on active scene, Players(Not GM) gets errors when the GM copy and pastes tokens

Used Find Culprit to confirm its Token Replacer.
Also did manual testing of disabling everything but Token Replacer (and tokenizer dependant)
(LEFT IS GM - RIGHT IS PLAYER)

Copying and Pasting tokens with TOKEN REPLACER disabled does not give player Errors.

Also verified USER PERMISSIONS were granting permissions to players regarding Tokens and Actors.

I'm releasing a new version in the next few minutes that should fix this. Please let me know.

authors: MagicOriole vtt-lair

repo: vtt-lair/token-replacer


text:
Update README.md

Added website
General

✏ Mark the necessary items without changing the structure of the PR template.

[ ] Pull request template structure not broken

Type

ℹ  What types of changes does your code introduce?

👉 Put an x in the boxes that apply

[ ] Fix
[ ] Feature

Checklist

ℹ  Check all checkboxes - this will indicate that you have done everything in accordance with the rules in CONTRIBUTING.

👉  Put an x in the boxes that apply.

[ ] Title as described
[ ] Make sure you put things in the right category!
[ ] Always add your items to the end of a list

Open Source

[ ] Link description does not contain a link to an author / third-party resource
[ ] The documentation (README) contains a description of the project, illustration of the project with a demo or screenshots and a CONTRIBUTING section
[ ] The documentation is in English.
[ ] The project is active and maintained.
[ ] The project accepts contributions.
[ ] Not a commercial product

Apps/Websites

[ ] The website is available without errors or ssl certificate problems, and load in a reasonable amount of time.
[ ] The website is using vuejs intensively. It should detect vue with vue-devtools.

If you cannot detect vue with vue-devtools due to work at non public pages (e.g. for enterprise website), you can send Pull Request with screenshot that detected it.

[ ] The website is original and not too simple. For that reason, blogs and simple landing pages are rejected.
[ ] A commercial product using Vue, provided that guests could reasonably check out how Vue was used A commercial product using Vue, provided that guests could reasonably check out how Vue was used (i.e. A headless CMS which uses Vue for the Admin/editor Area and offers a free tier).

Its not a vue site, and description is wrong. Spam I guess

authors: Jogai rahulkhorwal

repo: vuejs/awesome-vue


text:
[BUG] When using a number input, pressing arrow keys creates an invalid node type warning.

🐛 Bug description
When using a number input, pressing arrow keys creates this warning.
<input type="number"/>

🏞 Desired result
No warning.

🚑 Other information

Edit: TBH I don't know if this is a JSX problem or a Vue3 problem. If it's a Vue problem I'll forward this issue to their repo.

Please leave a reproduction repo

@whaaaley, would be nice to see a reproduction repo, because I do not have that problem.

Please I don't know much about Javascript I really wanna learn Please can anyone teach me etc

repo: vuejs/babel-plugin-jsx


text:
fix(Suspense): avoid unmount activeBranch twice if wrapped in transition

close #7966
the root cause is that the suspense resolves before the fallback node is mounted. This caused component B to be unmounted twice, causing this issue when it was unmounted the second time. see simplified demo
Notice the Console, unmount was printed twice.

@edison1105 I don't think the solution is good enough, from what I could gather this is caused by the renderer.ts
Basically the unmount is being called multiple times on the vnode, I wonder if we could replace the condition on suspense with a non altering flag on suspense.
I suppose it would make sense the vnode to know it has been unmounted therefore if unmounted is called again it should be ignored, some input from @yyx990803 would be great :)

@pikax
That's a great idea. I changed the solution.

/ecosystem-ci run

repo: vuejs/core


text:
devtools does not show the setup section of a component for vite build

Version
6.0.0-beta.15
Browser and OS info
Chrome 92, Mac Big Sur 11.4
Steps to reproduce
How to create a project by vite (documentation)

Run npm init vite@latest
Enter name
Select Vue (not vue-ts)
Run npm install

Devtools shows "setup" section for dev-server:

Run npm run dev (It starts dev-server for development)
Open http://localhost:3000/
Open devtools
Component "HelloWorld" contains "setup" section in devtools

Devtools doesn't show "setup" section for my build (And component displayed as `Anonymous Component"):

Replace vite build by vite build --mode development inside package.json
Run npm run build. "Dist" folder will be created
Serve the folder using instrument what you prefer. (npm run serve doesn't work for me. I used Golang with http.FileServer for static files and http.ServeFile for index.html)
Open url of your server
Open devtools
Component "HelloWorld" has name Anonymous Component and doesn't contain "setup" section in devtools

What is expected?
Devtools shows "setup" section for my result build (not only for dev-server)
What is actually happening?
Devtools doesn't show "setup" section for my result build

package.json
{
  "name": "vite-project",
  "version": "0.0.0",
  "scripts": {
    "dev": "vite",
    "build": "vite build --mode development",
    "serve": "vite preview"
  },
  "dependencies": {
    "vue": "^3.0.5"
  },
  "devDependencies": {
    "@vitejs/plugin-vue": "^1.3.0",
    "@vue/compiler-sfc": "^3.0.5",
    "vite": "^2.4.4"
  }
}

vite.config.js
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue()]
})

I've the same problem here.

authors: Neyury oliverzy

repo: vuejs/devtools


text:
vue-tsc behavior inconsistent with Volar

Repro case: https://github.com/yyx990803/vue-tsc-3.3-type-repro
Run npx vue-tsc --noEmit response with the following error:
test/index.ts:6:4 - error TS2339: Property 'msg' does not exist on type '{ $: ComponentInternalInstance; $data: {}; $props: Partial<{}> & Omit<Readonly<ExtractPropTypes<{}>> & VNodeProps & AllowedComponentProps & ComponentCustomProps, never>; $attrs: Data; $refs: Data; $slots: Readonly<InternalSlots>; $root: ComponentPublicInstance<{}, {}, {}, {}, {}, {}, {}, {}, false, ComponentOptionsBase<any, any, any, any, any, any, any, any, any, {}, {}, string>, {}> | null; $parent: ComponentPublicInstance<{}, {}, {}, {}, {}, {}, {}, {}, false, ComponentOptionsBase<any, any, any, any, any, any, any, any, any, {}, {}, string>, {}> | null; $emit: (event: string, ...args: any[]) => void; $el: any; $options: ComponentOptionsBase<Readonly<ExtractPropTypes<{}>>, {}, {}, {}, {}, ComponentOptionsMixin, ComponentOptionsMixin, {}, string, {}, {}, string> & MergedComponentOptionsOverride; $forceUpdate: () => void; $nextTick: <T = void>(this: T, fn?: ((this: T) => void) | undefined) => Promise<void>; $watch<T extends string | ((...args: any) => any)>(source: T, cb: T extends (...args: any) => infer R ? (args_0: R, args_1: R) => any : (...args: any) => any, options?: WatchOptions<boolean> | undefined): WatchStopHandle; } & Readonly<ExtractPropTypes<{}>> & ShallowUnwrapRef<{}> & ExtractComputedReturns<{}> & ComponentCustomProperties & {}'.

6 vm.msg;

But Volar with takeover mode in VSCode do not have this problem.

Maybe related to this: https://github.com/vuejs/language-tools/issues/2543

I meet the same problem in my project:
npm run check

> check
> vue-tsc --noEmit

src/layouts/page-layout/PageMobileMenu.vue:27:15 - error TS2339: Property 'open' does not exist on type '{ $: ComponentInternalInstance; $data: {}; $props: Partial<{}> & Omit<Readonly<ExtractPropTypes<{}>> & VNodeProps & AllowedComponentProps & ComponentCustomProps, never>; ... 10 more ...; $watch<T extends string | ((...args: any) => any)>(source: T, cb: T extends (...args: any) => infer R ? (args_0: R, args_1: R) => ...'.

27       :value="open"
                 ~~~~

src/layouts/page-layout/PageMobileMenu.vue:47:11 - error TS2339: Property 'close' does not exist on type '{ $: ComponentInternalInstance; $data: {}; $props: Partial<{}> & Omit<Readonly<ExtractPropTypes<{}>> & VNodeProps & AllowedComponentProps & ComponentCustomProps, never>; ... 10 more ...; $watch<T extends string | ((...args: any) => any)>(source: T, cb: T extends (...args: any) => infer R ? (args_0: R, args_1: R) => ...'.

47           close()
             ~~~~~

src/layouts/page-layout/PageLang.vue:43:22 - error TS2339: Property 'active' does not exist on type '{ $: ComponentInternalInstance; $data: {}; $props: Partial<{}> & Omit<Readonly<ExtractPropTypes<{}>> & VNodeProps & AllowedComponentProps & ComponentCustomProps, never>; ... 10 more ...; $watch<T extends string | ((...args: any) => any)>(source: T, cb: T extends (...args: any) => infer R ? (args_0: R, args_1: R) => ...'.

43             :class="[active && `bg-stone-100`]"
                        ~~~~~~

@johnsoncodehk Hi dear author, any update on this bug?
My project see too many this error, practically making vue-tsc unusable.

The problem is that vue-tsc version (v1.0.24) inconsistent with Volar (v1.3.x).

authors: johnsoncodehk xieyuheng

repo: vuejs/language-tools


text:
Add ability to disable automatic url generation

Hi. Is it possible to add some option, a switch, so I could turn on/off automatic URL generation or maybe a button to copy generated URL to the clipboard? (and the setting would be saved in localStorage). My reason is that every time I change the code, the url is also updated, making the browser history cluttered with unnecessary entries. I always have to remember to open the playground in incognito mode to bypass this, which is a little annoying to me  :/. Thanks for considering my request.
long, long list...

Closing since I opened this issue in the wrong repo. Sorry about that.

repo: vuejs/repl


text:
hmr not work for mock data

Version
3.0.0-rc.5
Reproduction link
https://gitee.com/li-xiaoyin/vue-mock.git
Steps to reproduce

create a folder named "mock" under the project.

modify vue.config.js like this：
....
before: app => {
require("fs")
.readdirSync(require("path").join(__dirname   "/mock"))
.forEach(file => require("./mock/"   file)(app));
}
....

edit mock script and then mock server worked very well

modify mock script

What is expected?
hmr is work
What is actually happening?
hmr not work.

I put the mock folder under the "src" and hmr is not work too

dva-cli support mock hmr without any code, may vue supported too？
see https://github.com/dvajs/dva

https://gitee.com/li-xiaoyin/umi-mock-middleware

repo: vuejs/vue-cli


text:
Watchers for arrays don't fire on 'add' triggers

Version
3.0.0-beta.14
Reproduction link
https://codesandbox.io/s/vue-3-watcher-error-goox1
Steps to reproduce
I assume that when watching an array, the watcher would fire when items are added.
const state = reactive({ items: [] })

watchEffect(() => console.log(state.items))

state.items.push('foo')  // expect watcher to fire

What is expected?
the watchEffect fires when items are added to the array
What is actually happening?
the watchEffect does not fire

This is expected behavior. state.items only tracks the mutation of the .items binding, it doesn't track deep mutations of the items array itself.
You can either add { deep: true }, which is inefficient, or replace the array with state.items = state.items.concat('foo')

Ok, fair! I figured it might be intentional. My next question is why it triggers when I just watch the state object, even with deep: false. for example:
const state = reactive({ items: [] })

watch(state, () => console.log('watcher fired'), { deep: false } )

state.items.push('foo')  // the watcher DOES fire in this case

When you directly watch a reactive object, it is implicitly deep because it would be pointless if it's not a deep watch.

repo: vuejs/vue-next


text:
refactor( reactivity): maybe reduce a function call.

or for some other purpose, tanks

This is likely intended, did you test this change's effect on build size?🤔

This is intended for tree-shaking.


text:
keep-alive的路由组件在去除过渡效果后，点击会同样作用于目标页面

<keep-alive>           <router-view></router-view>         </keep-alive>
在第一个页面点击链接后，跳转到第二个页面，此时无异常
退回第一个页面后，再次点击同一链接，跳转到第三个页面，第三个页面的链接在第二个页面点击的同一位置

请用jsfiddle/jsbin之类的工具给重现

请关闭这个问题，已经确认该问题的原因是一个插件将click模拟为tap动作时导致的

authors: fnlctrl nothinggift

repo: vuejs/vue-router


text:
Mocking Parameterized Getter Results in TypeError

Mocking Parameterized Getter Results in TypeError
I am writing a unit test for a component which uses Vuex. For the test, I am creating a mock store with a mocked parameterized getter which the components binds to an attribute in one of the components in the template. The dev build is compiled successfully and works expected in the browser but, not in the test environment. Here's what it throws:

console.error node_modules/vue/dist/vue.runtime.common.dev.js:621
[Vue warn]: Error in render: "TypeError: Cannot read property '_modulesNamespaceMap' of undefined"
  found in

  ---> <Anonymous>
         <Root>
console.error node_modules/vue/dist/vue.runtime.common.dev.js:1884
  TypeError: Cannot read property '_modulesNamespaceMap' of undefined
      at getModuleByNamespace (D:\Sites\assignment-papershift-cart-firebase-vue\node_modules\vuex\dist\vuex.common.js:1130:22)
      at VueComponent.mappedGetter (D:\Sites\assignment-papershift-cart-firebase-vue\node_modules\vuex\dist\vuex.common.js:1017:25)

Steps to reproduce

Create a component that mapGetters and binds parameterized getter to any attribute. In my case, I have AppButtonCardAdd component and binding to disabled attribute:

<template>
   <base-button :disabled="isProductInCart(productId)">

  </base-button>
</template>

Write a unit test that mocks that parameterized getter:

it('is not disabled as product is not in cart'. () => {
   actions = {
      addProductToCart: jest.fn()
    };

    getters = {
      isProductInCart: () => () => {
        return false;
      }
    };

    store = new Vuex.Store({
      modules: {
        cart: {
          actions,
          getters,
          namespaced: true
        }
      }
    });

    wrapper = mount(AppButtonCartAdd, {
      localVue,
      store,
      propsData: {
        productId: "1"
      }
    });
});

Expected behaviour
It should not throw TypeError. Instead, the test should pass with beautiful green output.
Actual behaviour
It throws TypeError.
Possible Solution
No idea. I need the getter to be parameterized.

Hi,
Can't run your test right now, but just in case – can you double check that you are injecting Vuex to localVue? localVue.use(Vuex). your snippet is missing that bit, and the error seems related.

@afontcu Thanks for looking at it. I didn't include the complete file. Here's the complete file for reference. You can put that test in the original comment in it and check. By the way, I used parameterized getter in some other component and it worked fine. The only difference is of mount vs shallowMount.
import { mount, createLocalVue } from "@vue/test-utils";
import Vuex from "vuex";
import AppButtonCartAdd from "@/components/AppButtonCartAdd";
import BaseButton from "@/components/BaseButton";

const localVue = createLocalVue();

localVue.use(Vuex);
localVue.component("base-button", BaseButton);

let wrapper = null,
  store = null,
  getters = null,
  actions = null;

afterEach(() => {
  wrapper.destroy();
});

describe("AppButtonCartAdd.vue", () => {
  beforeEach(() => {
    actions = {
      addProductToCart: jest.fn()
    };

    getters = {
      isProductInCart: () => () => {
        return false;
      }
    };

    store = new Vuex.Store({
      modules: {
        cart: {
          actions,
          getters,
          namespaced: true
        }
      }
    });
  });

  it("renders the button", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      propsData: {
        productId: "1"
      }
    });

    expect(wrapper.get("button"));
  });

  it("dispatches addProductToCart action on click", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      store,
      propsData: {
        productId: "1"
      }
    });

    const button = wrapper.get("button");

    expect(actions.addProductToCart).toHaveBeenCalledTimes(0);

    button.trigger("click");

    expect(actions.addProductToCart).toHaveBeenCalled();
  });

  it("renders after slot content", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      store,
      propsData: {
        productId: "1"
      },
      scopedSlots: {
        after: '
Add After
'
      }
    });

    const afterContent = wrapper.get(".add-after");

    expect(afterContent.text()).toBe("Add After");
  });

  it("renders before slot content", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      store,
      propsData: {
        productId: "1"
      },
      scopedSlots: {
        before: '
Add Before
'
      }
    });

    const beforeContent = wrapper.get(".add-before");

    expect(beforeContent.text()).toBe("Add Before");
  });
});

// TODO: Add tests for disabled prop based on isProductInCart getter
// See https://github.com/vuejs/vue-test-utils/issues/1616

@afontcu Here's the complete file:
import { mount, createLocalVue } from "@vue/test-utils";
import Vuex from "vuex";
import AppButtonCartAdd from "@/components/AppButtonCartAdd";
import BaseButton from "@/components/BaseButton";

const localVue = createLocalVue();

localVue.use(Vuex);
localVue.component("base-button", BaseButton);

let wrapper = null,
  store = null,
  getters = null,
  actions = null;

afterEach(() => {
  wrapper.destroy();
});

describe("AppButtonCartAdd.vue", () => {
  beforeEach(() => {
    actions = {
      addProductToCart: jest.fn()
    };

    getters = {
      isProductInCart: () => () => {
        return false;
      }
    };

    store = new Vuex.Store({
      modules: {
        cart: {
          actions,
          getters,
          namespaced: true
        }
      }
    });
  });

  it("renders the button", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      propsData: {
        productId: "1"
      }
    });

    expect(wrapper.get("button"));
  });

  it("dispatches addProductToCart action on click", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      store,
      propsData: {
        productId: "1"
      }
    });

    const button = wrapper.get("button");

    expect(actions.addProductToCart).toHaveBeenCalledTimes(0);

    button.trigger("click");

    expect(actions.addProductToCart).toHaveBeenCalled();
  });

  it("renders after slot content", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      store,
      propsData: {
        productId: "1"
      },
      scopedSlots: {
        after: '
Add After
'
      }
    });

    const afterContent = wrapper.get(".add-after");

    expect(afterContent.text()).toBe("Add After");
  });

  it("renders before slot content", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      store,
      propsData: {
        productId: "1"
      },
      scopedSlots: {
        before: '
Add Before
'
      }
    });

    const beforeContent = wrapper.get(".add-before");

    expect(beforeContent.text()).toBe("Add Before");
  });
});

describe("AppButtonCartAdd.vue without product in cart", () => {
  beforeEach(() => {
    actions = {
      addProductToCart: jest.fn()
    };

    getters = {
      isProductInCart: () => () => {
        return false;
      }
    };

    store = new Vuex.Store({
      modules: {
        cart: {
          actions,
          getters,
          namespaced: true
        }
      }
    });
  });

  it("is not disabled as the product is not in cart", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      store,
      propsData: {
        productId: "1"
      }
    });

    const button = wrapper.get("button");

    expect(button.element.disabled).toBe(false);
  });
});

describe("AppButtonCartAdd.vue with product in cart", () => {
  beforeEach(() => {
    actions = {
      addProductToCart: jest.fn()
    };

    getters = {
      isProductInCart: () => () => {
        return true;
      }
    };

    store = new Vuex.Store({
      modules: {
        cart: {
          actions,
          getters,
          namespaced: true
        }
      }
    });
  });

  it("is disabled as the product is in cart", () => {
    wrapper = mount(AppButtonCartAdd, {
      localVue,
      store,
      propsData: {
        productId: "1"
      }
    });

    const button = wrapper.get("button");

    expect(button.element.disabled).toBe(true);
  });
});

I found the issue. The stack trace actually lead me to the actual test case for which the TypeError was being thrown. In that test case, I missed passing the store object and hence that error. This is not a bug on vue-test-utils.
@afontcu Thanks for looking at it anyway.

authors: afontcu dev-talha-akbar

repo: vuejs/vue-test-utils


text:
css animations when leave bug

when i add transition attribution into Dom class ,the dom will be not removed after animationend,
in fact by javascript hooks log ,i found   the afterLeave function  not run  after leave
sorry for my bad english.
you  can see the below demo:
compare
http://jsfiddle.net/teddyzhu/5zer9try/
with
http://jsfiddle.net/5zer9try/2/
is it a bug or something wrong ?
test it in OS X 10.11.2  and Chrome 47.0.2526.106 (64-bit)

You should define CSS rules for .expand-transition, .expand-enter and .expand-leave classes.
http://vuejs.org/guide/transitions.html#CSS_Transitions
http://jsfiddle.net/5zer9try/1/

i defined the class *-enter and *-leave but they only have animation
in your example ,you add opacity: 0; into the enter and leave class
can i only use CSS Animations ?

@pespantelis  you can compare  http://jsfiddle.net/teddyzhu/5zer9try/ and http://jsfiddle.net/5zer9try/2/

@yyx990803  ok ,i see,thank you very much,this made me crazy before

@yyx990803  ok ,i see,thank you very much,this made me crazy before

authors: Teddy-Zhu pespantelis

repo: vuejs/vue


text:
Using Vue.component from extended component has dependency issues

As discussed in #1297 comments, using .component method on an inherited item does not transmit the components from the inherited elements:
var Root = Vue.extend()

Root.component('Foo', {
	template: '
Foo
'
});

Root.component('Bar', {
    // We expect bar to be aware about foo, because foo was registered globally
	template: '
Bar, uses <foo></foo>
'
});

new Root({
	template: '
<bar></bar>
'
}).$mount('#app')

// Throws: [Vue warn]: Unknown custom element: <foo> - did you register the component correctly? For recursive components, make sure to provide the "name" option. (found in component <Bar>)

This fails because Bar component was built with Vue.extend instead of Foo.extend : https://github.com/vuejs/vue/blob/dev/src/global-api.js#L216
I would like to tell that it is an issue and the factory should use this.extend instead of the static Vue.extend, but in the unit test it's already defined like that: https://github.com/vuejs/vue/blob/dev/test/unit/specs/global_api_spec.js#L105
Though there is an obvious workaround (Root.component('Bar', Root.extend);), I think the way the factory works is ambiguous and leads to confusion.
What's your thoughs?

This is expected behavior. Only Vue.component registers global components.

@yyx990803 your answer is not answering my question.
I dont ask about Root.component for registering global component. Instead I ask about the factory of Root.component creating Vue instance and not Root instance

Well, it will be simpler explained this way:
Root.component('Foo', {
    template: '
Foo
'
});

is equivalent to
Root.component('Foo', Vue.extend({
    template: '
Foo
'
}));

When I was expecting it to be equivalent to:
Root.component('Foo', Root.extend({
    template: '
Foo
'
}));

Then it doesn't make sense. Component registration is a separate concern from component inhertence. implicitly mixing the two doesn't sound like a good idea to m AND is a breaking change, so no.


text:
Await async component lifecycle hooks

What problem does this feature solve?
If a user needs to implement a lifecycle hook that depends on async operations, vue should respect the async nature of the implemented hook and await it in vue land.
What does the proposed API look like?
The API does not change; only how it works now by awaiting async hooks.

So you want
created () {
    return new Promise(resolve => {
        setTimeout(() => {
            console.log('created')
            resolve()
        })
    })
},
mounted () {
    console.log('mounted')
}

to display
created
mounted

?
When creating a feature request, please add a real-world use case to make the request worth being implemented.

While this is theoretically a cool idea, this requires a fundamental rethink/rewrite of the architecture to achieve, and can potentially break a lot of logic that relies on the synchronous nature of lifecycle hooks. So the benefits must be substantial in order to justify that change - otherwise this can only be considered when we plan to do a full breaking upgrade, which is unlikely to happen very soon.
Closing for now, but feel free to follow up with more concrete reasoning / use cases / implications.

@posva Understood -- I apologize. My actual use case is one where I have a UserPage component that receives a user_id from the page route parameters (through this.$route.params), then fetches the actual user data from the database on the server using a command like:
this.user = await client.get({type: 'user', id: this.$route.params.id})
where this.user refers to a user field in the data part of the UserPage component.
Ideally, I want that line of code to be executed after the component has been created (so that this.$route.params is available) but before the component is actually mounted so that in my template I can safely use user interpolations without getting any errors about undefined values.
@yyx990803
I might be a noob here, but shouldn't the only change be adding the await keyword before the call for lifecycle hooks like mounted, etc, in Vue land?

This is the actual code that I want to be awaited:
  beforeMount: async function() {
       this.user = await client.get({type: 'user', id: this.$route.params.id});
    }

Which would be part of the UserPage component.

No worries! I was imagining that use case. It's better to handle it as described in vue-router docs as it opens different ways of displaying loading state. You can already wait for the data to be there before rendering the component btw.

OK that makes sense. Now, however, what if I have a user component that is a stripped down version of the user page (say, like the component that appears when you hover over a user's name on facebook and "peek" into their profile), then the router is not involved here and the id will be passed as a property to the component.

Taking the big picture view here, functions in JavaScript can now be either synchronous or asynchronous, and that lifecycle hooks being functions, and the way we think of them as functions, should support asynchronousity (as demonstrated by my use case and intuitive "reach" for the approach I am using here).

You have many ways of doing it. The simplest one is using a variable that starts as null, fetch the data and set it, toggling the actual component (because of a v-if). A more exotic version would be a function that resolves the component and use a <component :is="myDynamicComp"/> 😄
But please, don't hijack the issue into a question 😉 use the forum or discord for that

No I really don't want help with the code! Actually I already have implemented workarounds very similar to your suggestions. What I am trying to say is that it is much more intuitive to just use JS async features.

The part I didn't realize is that asynchronous and synchronous code are fundamentally different in nature, so that synchronous code cannot be forced to adhere to asynchronous code without fundamentally changing itself to asynchronous code. yyx990803 saw it immediately but it took me some time to understand his comment completely. Thanks for your time guys and sorry if there was a miscommunication on my part somewhere through the way.

A possible more "flat" solution:
{
    async created () {
        let createdResolve = null
        let createdReject = null
        this.createdPromise = new Promise(function(resolve, reject){
            createdResolve = resolve
            createdReject = reject
        })
        await asyncCall1()
        await asyncCall2()
        ...
        createdResolve(someResult)
    }
    async mounted () {
        let result = await this.createdPromise
        ...
    }
    data () {
        return {
            createdPromise: null
        }
    }
}

Is this not a thing yet?

data() {
 ...
},
async created() {
  const something = await exampleMethod();
  console.log(something);
}

Is working for me (as @fifman mentions).

@breadadams Yes, of course. The functions inside the created method will be awaited - however the created or mounted function itself is not.
So the Vue instance will call created and instantly mounted before any of the long running processes in created are finished

Ah, my bad @darren-dev - different use case on my side, but I see the issue now 😅 thanks for clarifying.

@breadadams No problem at all - we're all here for our own cases, glad I could clarify!

Seems to me that allowing async support for the lifecycle methods will encourage bad UX practices by default. How? Async functions are used for requests that cannot be completed immediately (e.g. long-running or network requests). Forcing Vue to delay creation or mounting or any of the other lifecycle methods to wait on your network request or long-running asynchronous process will impact the user in noticeable ways. Imagine a user coming to your site and then having to wait for 4 seconds with a blank screen while the component waits for the user's spotty cell connection to finish your network request. And not only does this negatively impact the user but you are also sacrificing your control over the situation - there's nothing you can do as a developer to make the users perceived load time quicker, or show determinate or indeterminate progress indicators. So by building this ability into Vue you aren't making the web a better place; you're enabling bad practices.
Much better to plan and design for the asynchronous case from the get-go: kick off your asynchronous process in created or mounted or wherever, and then make your component have a skeleton structure or at worst a spinner while you wait for your API to return the user's permissions. Much better UX and you don't sacrifice any control. And Vue doesn't have to add code to deal with asynchronous lifecycle functions, keeping the bundle smaller. Win win.

@seanfisher You raise a  valid point. Architecturally speaking, designing around an asynchronous set of events should be handled by the developer - as that's the only way to portray the message correctly.
Disclaimer: The following is written with the idea of page generation in mind. There are definitely valid use-cases where my argument is invalid.

However, dictating the design patterns of a developer should not be left up to the framework you're using. My argument is that if you're not waiting for a phase to complete - then why have  different phases? Why have a created, then mounted stage? If everything is basically happening at once, then completely ignoring the created stage is okay.
Literally, the only time I've ever (Since early Vue) hooked into created was when I had to inject something vue needed to rely on - it had nothing to do with the setup or layout of my page. However, I have had to wait for (short) async tasks to run that would be much better before the page got rendered (Such as hooking into Firebase's authentication methods). Having that in create, then waiting for it to complete before mounted would reduce the need for hacky workarounds completley.
Remember, my argument is that Vue shouldn't tell me that Im developing wrong. It should just provide the desired functionality.

However, dictating the design patterns of a developer should not be left up to the framework you're using.

Um....Frameworks are built to specifically limit or guide or "frame" the developer into certain design patterns and practices. That's their main purpose. Any good framework will offer a smart API, which precisely offers a clear and obvious way to work with the framework and yet it will also be constraining.
Yes, it is paradoxical that a framework offers certain abilities, yet also constrains the developer at the same time to certain design practices. That is exactly where opinionation within Frameworks can either help or hurt it. It's a really hard to find that balance and I think Vue or rather Evan and the Vue dev team have done and are doing a great job making these judgement calls.
Scott

I'll never argue that a well designed framework should be extended with the same design pattern, but my argument is that the framework can't dictate it.

Sorry, but this makes no sense to me. Please show me one framework that doesn't dictate how it should be extended.
I thought my saying "Evan and Co making good judgement calls" would show my opinion. But, to be more clear. The mounted and created lifecycle hooks don't need to work asynchronously or rather, the fact they work synchronously helps with reasoning about the application logic. Any "waiting" needs to be accounted for in the UI anyway and asynchronous code can still be ran in each hook. We can argue about now necessary the beforeMount and mount hooks are. But, there might be a thing or two you might need in mounted, for instance, which you can't yet access in created, like the compiled render function.
Scott

If Vue has an opinion one way or the other on async lifecycle hooks it shouldn't be a matter of speculation. There is no need to speculate when the standards, APIs, guides and best practices Vue adopts, provides or recommends are available for all to read.
In Evan's original reply, async lifecycle hooks are not in the standard API not because it is necessarily a bad idea, but because the benefits are not substantial enough to justify the cost of implementation.
For the opinion that it is a bad practice to make the user wait for an async created or other lifecycle hook without an indicator that something is happening, the argument can be made that Vue, having supported async hooks, now maybe provides something which could be called "phase templates" that would also solve the problem (and which could be easy to implement).

For the opinion that it is a bad practice to make the user wait for an async created or other lifecycle hook without an indicator that something is happening,

Is this really even a problem?
Scott

Here is the issue I am having -- and maybe someone can suggest how I SHOULD be doing this because this appears problematic.
Our Vue application (rather large) uses Vuex extensively.  In quite a few of our Vue components in the create() lifecycle we set via store.dispatch() some items in the store (obviously).  However, as it has come to my attention -- store.dispatch() ALWAYS returns a promise .. even if the underlying logic and function is NOT async.  So I put in async created() {  await store.dispatch('foo/action') } but as noted that actually fails ..
I am also using Typescript and it complains rather bitterly when I don't await / .then the store.dispatch() calls .. having "floating" promises..
So what's the best way to use Vuex store.dispatch() in a lifecycle when we can't async them?
Cheers!!

All other discussion aside, this behavior could stand to be documented more clearly.

Will an async lifecycle hook be considered for Vue 3.0?

I'm looking at @fifman 's "more flat" solution above, and I'm not sure it solves the issue for me, which is ensuring I've loaded my XHR by the time mounted() returns. In that solution, both created() and mounted() are async, so Vue will call each of them and they'll return more or less immediately, with the async stuff going on in the background. In fact I'm not sure how that's better than just doing away with the createdPromise and just doing all the async work in either created() or mounted(), like:
async mounted() {
  let response = await fetch(my_url)
  let data = await response.text()
  my_data_member = data
}

In any case, my_data_member will be filled in "later" when the XHR completes, long after mounted() returns its Promise, right?

You can also try to use v-if on root component <div id="app"/> and trigger it when your data loading finished. I, for example ,use it for refresh token.

This is a cool feature to have and have lots of use cases. For my usecase I need to load specific API properties before the actual render of the component. However, i don't feel that async in life cycle hooks is an ideal solution.
Currently everyone is mentioning here a perfect scenario where the async functions runs smoothly. But lets say for eg if the users connection is slow or lagging and we wait for the component to mount after the response of an API, then the whole component life cycle is distributed. We won't be able to show loading information to the user. Or far worse, if the API times out or returns error, the application will hang without mounting.
Though this is a cool feature to have, I would suggest for it to be handled by application rather then the framework because the domain logic implementation has more insight on the underlying logic then the framework thus creating less side effects.

+1 for this feature.
I have a mixin used by various components, the mixin fetches data from a database in the mounted hook.
The components have to work with the data fetched by the mixin also in the mounted hook.
As it is now, i had to implement a callback to be called when the mixin has finished loading the data and ditch the mounted hook in the component.
It works but would be prettier if the mounted hook handled promises.

@cederron purely out of interest, why can't you download the data in the parent component and pass it in as a prop? use a v-if to show a loading indicator while the data loads and when the data shows up, you can show the component, and when it is created, it will have all of the data that it needs.
Avoids having the component represent two distinct unrelated states ('no data loaded, waiting' and 'data has been loaded, you can manipulate it')
If you need to reuse the logic in multiple places, might even move the download logic to Vuex, kinda makes sense as downloading data would go in a Vuex action rather than a component.

@ReinisV  I think I simplified my case too much, the component creates new data from the data fetched by the mixin mounted hook, and component view is binded to this new data.
So, the mixin has to fetch data from the database > the component creates data from it > now the component is shown
AFAIK this wont work:
export const MyMixin = {
    data: function () {
        return {
            dbData: null
        }
    },
   mounted:  function () {
      asyncFetchDataFromDB().then( (d) => dbData = d )
   }
}

export const MyComponent = {
    mixins: [MyMixin],
    data: function () {
        return {
            newData: null
        }
    },
   mounted:  function () {
      this.newData = handleDBData(this.dbData)
   }
}

dbData will be null in component mount hook.
Currently I  execute a callback when the mixin fetches the data but would be prettier to just make the mount function async.
Can not say much about vuex as I'm not using it

I really want to reiterate what @seanfisher mentioned here. Having vue wait on components which have been marked as async not only causes issues for the users, the pattern of using async/await to start data look up is present everywhere. It would force explicitly converting the code in these lifecycle hooks to unawaited promises to explicitly avoid blocking vue.  In some cases it might be good, and if a feature would be introduced, I would have to suggest running two lifecycles at the same time, the current one which handles component hooks execution and one which awaits those executions for global callbacks.
But I really would be disappointed to literally rewrite every one of my lifecycle hooks to avoid blocking vue, async/await is much cleaner, so we don't use promises. Changing this in a non-backwards compatible way changes the pit of success (unawaited component lifecycle) for a pit of failure.

Instead of trying to make asynchronous call in the component lifecylce hooks, why don't you use an synchronous component instead?
new Vue({
  components: {
    root: () => ({
      component: new Promise(async function (resolve) {
      }),
      loading:
    })
  },
  render: h => h('root')
})

while most of these solutions seem fine, I think this is one of those major missing pieces of Vue that make it so intuitive. I think Vue 3 needs to implement this as we have come to the point where using async await is now an everyday thing. SO PLEASE @yyx990803 You, let's have it in Vue 3. PLEEEEEEEASE. The whole VUE architecture was made without assumption to these cases and most of the things that people are posting here are just workarounds and hackish. I think hooks should actually respect return values.
I trying to load a component defined in the props that are passed to the component that needs this functionality. So in created it await for the component to be loaded before mounted is fired. It'd be great to have mounted fired only when told to do so. I going to refactor my code seeing this isn't being honoured, but ugly code will come out of it since it'd be a hack.

Seems to me that allowing async support for the lifecycle methods will encourage bad UX practices by default. How? Async functions are used for requests that cannot be completed immediately (e.g. long-running or network requests). Forcing Vue to delay creation or mounting or any of the other lifecycle methods to wait on your network request or long-running asynchronous process will impact the user in noticeable ways. Imagine a user coming to your site and then having to wait for 4 seconds with a blank screen while the component waits for the user's spotty cell connection to finish your network request. And not only does this negatively impact the user but you are also sacrificing your control over the situation - there's nothing you can do as a developer to make the users perceived load time quicker, or show determinate or indeterminate progress indicators. So by building this ability into Vue you aren't making the web a better place; you're enabling bad practices.
Much better to plan and design for the asynchronous case from the get-go: kick off your asynchronous process in created or mounted or wherever, and then make your component have a skeleton structure or at worst a spinner while you wait for your API to return the user's permissions. Much better UX and you don't sacrifice any control. And Vue doesn't have to add code to deal with asynchronous lifecycle functions, keeping the bundle smaller. Win win.

One opinion of thousands. Just because you can't imagine a scenario where component rendering being delayed can live alongside a positive user experience doesn't mean it doesn't exist.
If a framework fights the developer the developer will find another framework.

@robob4him

One opinion of thousands. Just because you can't imagine a scenario where component rendering being delayed can live alongside a positive user experience doesn't mean it doesn't exist.

If a framework fights the developer the developer will find another framework

You are absolutely right, but nothing you shared here is a valid argument to solve the problem one way or another.  You've introduced a scare tactic to coerce the community into developing a feature. Not a constructive continuation of the conversation.

@wparad, it's absolutely a scare tactic, but it's not going to coerce anyone into doing anything. Putting forth arguments that a feature supports bad habits or anti-patterns or will decay the larger community of developers is just as much a scare tactic.
Half the features of literally any framework/language are hazardous to a developer; public methods can be extended, Vue encourages access to the element ($el), etc. Frameworks provide these things because at the end of the day the developer needs to get the job done.
This feature request is a year old. People should understand that the reason is not actually because it would cause bad practices nor should they perceive delayed rendering as a bad practice.

I need to use requirejs with vue. Not that I like requirejs but because I want to use vue with an open source LMS which has all it's modules as AMD modules. It'd be great if I could load all the libs I need in the beforeCreate hook. The alternative for me at the moment is to load them outside  of vue and then pass them in which is messier.

Seems to me that allowing async support for the lifecycle methods will encourage bad UX practices by default. How? Async functions are used for requests that cannot be completed immediately (e.g. long-running or network requests). Forcing Vue to delay creation or mounting or any of the other lifecycle methods to wait on your network request or long-running asynchronous process will impact the user in noticeable ways. Imagine a user coming to your site and then having to wait for 4 seconds with a blank screen while the component waits for the user's spotty cell connection to finish your network request. And not only does this negatively impact the user but you are also sacrificing your control over the situation - there's nothing you can do as a developer to make the users perceived load time quicker, or show determinate or indeterminate progress indicators. So by building this ability into Vue you aren't making the web a better place; you're enabling bad practices.
Much better to plan and design for the asynchronous case from the get-go: kick off your asynchronous process in created or mounted or wherever, and then make your component have a skeleton structure or at worst a spinner while you wait for your API to return the user's permissions. Much better UX and you don't sacrifice any control. And Vue doesn't have to add code to deal with asynchronous lifecycle functions, keeping the bundle smaller. Win win.

What you are saying is like adding v-if/v-clock/v-show features will encourage bad practices so we better fool-proof the framework by removing those features. Then use some convoluted approach to do the same so that Vue is smaller for not putting those 3 directives. First developers aren't stupid, fool-proofing the framework in turn limits its usability because you are limiting what can be done based on apparent "fools". Why would one put a v-if for their entire website to block it thru async operations leaving the entire screen blank?
I think you are ignoring the fact that most of the use cases may not even be with a blank page. They are called components for a reason. Cases where I personally want to use this is where something is already on the screen doing something else. This maybe a component blocked by a v-if for instance and triggered when something changes. However, in the process of rendering it for the first time, async functions etc need to be respected as the component boots. I grazed the entire Vue documentation looking for this and finally did it with a very not so pretty workaround like above hackish examples.
What worries me is someone/even later me maintaining the code. It's like the Promise callback hell vs Async ... Await.
Actually I see it enhancing the framework's flexibility and controllability in an easy to followup fashion. Just take a look at the hacks above to see what I mean. Developers are doing all that just to fill in the gap of a simple async mounted () { await... } statement for example. If you don't want to use those features, you just don't define the functions as async or even use await at all.
Actually someone who will actually use an async mounted lifecycle hook will most likely understand what they are doing and why they will be doing it, and will most likely NOT make those bad practices you are worried about.

@emahuni, I don't think any would disagree with the expectation you are sharing, but I'm thinking there is a nuance, that is being left out. Let's assume that an async mounted or async created delays the component from being rendered.  What does the parent do in this case?  Does it:

block as well
assume that the component is meant to be removed the DOM v-if until it is done loading
assume that the component is meant to be hidden until completed loading
Show a temporary element in its place?

While I agree that the expectations around a dynamically loaded component are consistent, the behavior for the parent I don't think would be. In these cases, it would be IMO exposing the implementation of the child to the parent and force the parent to figure out what to do with that dynamic component. Instead how the data is loaded and the state of the child component should be up to the child. If it loads async then it needs some way to explain to Vue what should be rendered in its place (or not rendered). The best way to handle that is how the framework already works, rather than introducing a new complexity.
Further, I'm not totally following your argument though:

What you are saying is like adding v-if/v-clock/v-show features will encourage bad practices so we better fool-proof the framework by removing those features

While in this case, we can clearly see that introducing async components awaiting the mount or created will cause bad practices, it isn't clear that this does. Second, it is begging the question, even if those do cause bad practices, we should opt for fixing them, rather than using them as a justification for create new bad practices. If you know of bad practices that are being created by v-if, etc... I invite you share explicitly (in another issue of course) what the problem with those are, rather than trying to use that as a justification for a different discussion.

@emahuni, I don't think any would disagree with the expectation you are sharing, but I'm thinking there is a nuance, that is being left out. Let's assume that an async mounted or async created delays the component from being rendered. What does the parent do in this case? Does it:

block as well

The parent can go ahead and render without even waiting for the child, why should it? It can go right ahead and run updated once the child has rendered.

assume that the component is meant to be removed the DOM v-if until it is done loading

I am not sure I get this... but the answer is no, we don't assume it will be removed, it just needs to do something during mounted that has to block mounted during that time. There are a lot of use cases read above for that.

assume that the component is meant to be hidden until completed loading

This depends on the developer, why they are asyncing the mounted or any other hook for that matter.

Show a temporary element in its place?

That may not be the case at all. Again it depends with the developer what they intend to achieve. The point is, nothing should be straight jacketed. When, for instance, v-if was designed it wasn't because they conceived why someone would want to block the rendering of a component each time, and what they place instead and fool-proofed it. There are many things that can go wrong with v-if by developer design. You shouldn't worry what will be on screen during that time, that's not for the framework to worry about.

While I agree that the expectations around a dynamically loaded component are consistent, the behavior for the parent I don't think would be. In these cases, it would be IMO exposing the implementation of the child to the parent and force the parent to figure out what to do with that dynamic component. Instead how the data is loaded and the state of the child component should be up to the child. If it loads async then it needs some way to explain to Vue what should be rendered in its place (or not rendered). The best way to handle that is how the framework already works, rather than introducing a new complexity.

FYI: You agrees this needs to be implemented, however, it will introduce these complexities you are crying about and he feels that it may be done later when breaking changes are introduced rather than in Vue 3. The point being that he feels it is needed.

Further, I'm not totally following your argument though:

What you are saying is like adding v-if/v-clock/v-show features will encourage bad practices so we better fool-proof the framework by removing those features

While in this case, we can clearly see that introducing async components awaiting the mount or created will cause bad practices, it isn't clear that this does. Second, it is begging the question, even if those do cause bad practices, we should opt for fixing them, rather than using them as a justification for create new bad practices. If you know of bad practices that are being created by v-if, etc... I invite you share explicitly (in another issue of course) what the problem with those are, rather than trying to use that as a justification for a different discussion.

I merely pointed out those directives as an example of features that can be used incorrectly to block the rendering of a component similar to what you were saying about async.... Nothing wrong with them. So should we remove those directives just because someone can use "bad practices" to create components that show blank pages for a minute? Actually you don't see anybody doing that because it doesn't happen, unless you are trying to give an example of uttermost badness as in awful.
Look, the point is, if you can't see any use case yet, then don't say other people will use it badly and therefore it shouldn't be done. Bad practice is a matter of ignorance and someone that ignorant may never use these features altogether.
Someone asked this https://github.com/vuejs/vue/issues/7209#issuecomment-424349370 up there and nobody answered him as far as I saw. This is by far showing genuinely that Vue is legging behind on this part. This part of the architecture was designed when async wasn't a thing yet. So updating it to meet modern requirements for modern architectures is sure a good idea. Otherwise the rest is hackish and workarounds that need specific ways of doing it rather than do what's happening in the industry.
However, I am not sure yet, but looking at the new functional API at a glance seems like it may actually be possible to do this. Since it is functional it means one can do certain things they couldn't objectively do, like async lifecycle hooks.

Look, the point is, if you can't see any use case yet, then don't say other people will use it badly and therefore it shouldn't be done. Bad practice is a matter of ignorance and someone that ignorant may never use these features altogether.

Never made that point, I'm making the point that I want to perform async actions by default without ever blocking the component from rendering.  It is unintuitive that performing async actions in an mounted or created block will cause the rendering of the component to be delayed.  Assuming this was the case, I would instead see the complexity arise from how a consumer, who wants the current functionality would proceed. The argument so far isn't that what is being asked for, can't be done, it is that what is being asked for should be the default.  You can already block the rendering of your component by switching the displayed template based on a v-if="loaded".
Right now to render without blocking the code looks like this:
Right now that code is:
<template>
  <div>
    <spinner v-if="!loaded">
    <div>
      ....
    </div>
</template>

<script>
  async created() {
    await this.loadData();
    this.loaded = true;
  }
</script>

And to render with blocking looks the exact same way, since you can't actually block.  Assuming the async created() actually blocked the component. Then we now have a separation of code. To display the spinner, we write:
<template>
  <div>
    <spinner v-if="!loaded">
    <div>
      ....
    </div>
</template>

<script>
  created() {
    this.loadData().then(() => this.loaded = true);
  }
</script>

and just ignore rendering the component on the screen we write
<template>
  <div>
    <div>
      ....
    </div>
</template>

<script>
  async created() {
    await this.loadData();
  }
</script>

For what benefit does adding this simplification for blocking the rendering warrant making not blocking more complicated?  I'm just not seeing it.

Dependency handling for components
@yyx990803 Please take a look at this, it's not perfect, but a complex use case scenerio nevertheless.
Ok here is a use case that could have been elegantly handled if lifecycle hooks had async ... await:
I actually wished to do this in an app and got ugly code to achieve this. This is a very contrived example of coz
I need component A to await for component B && C's mounted hooks to fire before mounting itself. So component A's mounted has to await  its created hook, which triggered the mounting of component B && C that were waiting for the trigger (which can actually do something prior to waiting). Thing is it's easier this way and much much cleaner and intuitive as everything stays in one place for the concerned component.
A emits a trigger event and listens for responses from B and C (B and C wait for A's signal before continuing, then emit events once mounted) before continuing, simple. This is more like a dependency scenario for components without any extraneous data littered elsewhere for state management.
Main hosting component, all the components are loaded together, but wait for the right ones using events and async... await. It cares less what these children do, they order themselves.
<template>
  <div>
     ...
     <component-A/>
     <component-B/>
     <component-C/>
     ... other conent
  </div>
</template>
<script>
  import ComponentA...
  ...
  export default {
      components: { ComponentA... }
  }
</script>

component A controls the mounting of B and C as dependancies. The triggering could be done even later, it's just to show off the idea here.
<template>
  ...
</template>
<script>
  export default {
      async created() {
          // ...do something here before mounting thrusters, even await it
         this.root.$emit('mount-thrusters');
         await Promise.all([
            this.wasMounted('thruster-1-mounted'),
            this.wasMounted('thruster-2-mounted')
         ]);
      },
      mounted() {
        // will only run after components B and C have mounted
        ...
      },

     methods: {
       wasMounted(compEvent) {
          return new Promise( (resolve)=>this.root.$once(compEvent, ()=>resolve()));
       }
    }
  }
</script>

component B
<template>
  ...
</template>
<script>
  export default {
      async created() {
          // ...do something here, even await it, but happens at the same time as all components
         await new Promise( (resolve)=>this.root.$once('mount-thrusters', ()=>resolve()));
      },
     mounted() {
       this.root.$emit('thruster-1-mounted');
    }
  }
</script>

component C
<template>
  ...
</template>
<script>
  export default {
      async created() {
          // ...do something here, even await it, but happens at the same time as all components
         await new Promise( (resolve)=>this.root.$once('mount-thrusters', ()=>resolve()));
      },
     mounted() {
       this.root.$emit('thruster-2-mounted');
    }
  }
</script>

The code above can be simplified further by mixins seeing there are a lot of duplicate code snippets, I just wanted it to be clear. The wasMounted method can be canned in a mixin and used across all 3 components.
Here we can clearly see what each component is expecting without any other hackish or router code littered elsewhere to control the very same thing. It's very confusing to actually do this without this feature, believe me I have done this in an app.
This obviously gets rid of unnecessarily complex and unmaintainable code.
Now imagine this in a large App, with 32 thruster components that behave differently. You will only have about 3 points to mind, which are reducible to even 2 if you thrown in mixins.
Making things stay fresh
Of coz this is not only limited to mounted and created, but actually should work with all other lifecycle hooks.  Imagine if this is in a shiny new beforeActivate/beforeUpdate hook. We could make the component await activation/update and only activate/update when refreshment is done each time the component is activated/updated; making sure things stay fresh.
The list is endless once this is implemented.

Look, the point is, if you can't see any use case yet, then don't say other people will use it badly and therefore it shouldn't be done. Bad practice is a matter of ignorance and someone that ignorant may never use these features altogether.

Never made that point, I'm making the point that I want to perform async actions by default without ever blocking the component from rendering. It is unintuitive that performing async actions in an mounted or created block will cause the rendering of the component to be delayed. Assuming this was the case, I would instead see the complexity arise from how a consumer, who wants the current functionality would proceed. The argument so far isn't that what is being asked for, can't be done, it is that what is being asked for should be the default. You can already block the rendering of your component by switching the displayed template based on a v-if="loaded".
Right now to render without blocking the code looks like this:
Right now that code is:
<template>
  <div>
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  async created() {
    await this.loadData();
    this.loaded = true;
  }
</script>

And to render with blocking looks the exact same way, since you can't actually block. Assuming the async created() actually blocked the component. Then we now have a separation of code. To display the spinner, we write:
<template>
  <div>
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  created() {
    this.loadData().then(() => this.loaded = true);
  }
</script>

and just ignore rendering the component on the screen we write
<template>
  <div>
    <div>
      ....
    </div>
</template>

<script>
  async created() {
    await this.loadData();
  }
</script>

For what benefit does adding this simplification for blocking the rendering warrant making not blocking more complicated? I'm just not seeing it.

This is Vue 101 bootcamp and there is nothing new there... it's not sufficient to cover the above cases for example. The idea here is to reduce complexity in the userland where Vue is actually used and avail easier to reason-about code.
The rendering here is not the issue, it's what is happening before the render that is actually of consequence. We want the freedom to do things before proceeding or rendering a component.

I'm really confused by this, instead of coupling B & C to A, I would move
the code to "load A" into A.js and then have A.js update the "B.data" and
"C.data". That way if the A.data changes for any reason the other
components are automatically rerendered rather than trying to delegate
control from one component to another one.  Even in the case shared, I
would still decouple the data to render A from the *A *component.  We have
used a single class which contains methods like fetchData and *hasInitialized
*for which the latter is a promise and the former resolves the latter.
Directly coupling the components together creates unexpected dependency
trees which prevents the components from being reusable and allowing vue to
rerender them correctly.
Alternatively, I would even emit the event directly to the parent of A,
B, and C, and not on the global scope, and let the parent decide if to
render B and C, i.e.
   <a-component @rendered="showBandC = true" />
   <b-component v-if="showBandC" />
   <c-component v-if="showBandC" />

What is it about A that in this case we would actually need to render
before B and C renders.  If there is stuff in the created() method,
nothing prevents that from populating the store via a javascript class or
using a store module. But the explicit use case would more helpful, i.e.
what is the UX of the user story that can't be captured?
On Mon, Sep 30, 2019 at 8:37 PM Emmanuel Mahuni notifications@github.com
wrote:

Dependency handling for components
@yyx990803 https://github.com/yyx990803 Please take a look at this,
it's not perfect, but a complex use case scenerio nevertheless.
Ok here is a use case that could have been elegantly handled if lifecycle
hooks had async ... await:
I actually wished to do this in an app and got ugly code to achieve this.
This is a very contrived example of coz
I need component A to await for component B && C's mounted hooks to
fire before mounting itself. So component A's mounted has to await its
created hook, which triggered the mounting of component B && C that
were waiting for the trigger (which can actually do something prior to
waiting). Thing is it's easier this way and much much cleaner and
intuitive as everything stays in one place for the concerned component.
A emits a trigger event and listens for responses from B and C (B
and C wait for A's signal before continuing, then emit events once mounted)
before continuing, simple. This is more like a dependency scenario for
components without any extraneous data littered elsewhere for state
management.
Main hosting component, all the components are loaded together, but
wait for the right ones using events and async... await. It cares less what
these children do, they order themselves.

component A controls the mounting of B and C as dependancies. The
triggering could be done even later, it's just to show off the idea here.

component B

component C

The code above can be simplified further by mixins seeing there are a lot
of duplicate code snippets, I just wanted it to be clear. The wasMounted
method can be canned in a mixin and used across all 3 components.
Here we can clearly see what each component is expecting without any other
hackish or router code littered elsewhere to control the very same thing.
It's very confusing to actually do this without this feature, believe me I
have done this in an app.
This obviously gets rid of unnecessarily complex and unmaintainable code.
Now imagine this in a large App, with 32 thruster components that behave
differently. You will only have about 3 points to mind, which are reducible
to even 2 if you thrown in mixins.
Making things stay fresh
Of coz this is not only limited to mounted and created, but actually
should work with all other lifecycle hooks. Imagine if this is in a shiny
new beforeActivate/beforeUpdate hook. We could make the component await
activation/update and only activate/update when refreshment is done
each time the component is activated/updated; making sure things stay
fresh.
The list is endless once this is implemented.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vuejs/vue/issues/7209?email_source=notifications&email_token=ABGSNWXZBKVZU3FCXXKKFLDQMJBQBA5CNFSM4EHMW47KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD76UG2Q#issuecomment-536691562,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABGSNWS3TYXK6PADEUYTMQDQMJBQBANCNFSM4EHMW47A
.

I'm really confused by this, instead of coupling B & C to A, I would move the code to "load A" into A.js and then have A.js update the "B.data" and "C.data". That way if the A.data changes for any reason the other components are automatically rerendered rather than trying to delegate
control from one component to another one. Even in the case shared, I would still decouple the data to render A from the *A *component. We have used a single class which contains methods like fetchData and hasInitialized for which the latter is a promise and the former resolves the latter.
Directly coupling the components together creates unexpected dependency trees which prevents the components from being reusable and allowing vue to rerender them correctly.
Alternatively, I would even emit the event directly to the parent of A, B, and C, and not on the global scope, and let the parent decide if to render B and C, i.e.
  <template>
    <a-component @rendered="showBandC = true" />
    <b-component v-if="showBandC" />
    <c-component v-if="showBandC" />
  </template>

What is it about A that in this case we would actually need to render before B and C renders. If there is stuff in the created() method, nothing prevents that from populating the store via a javascript class or using a store module. But the explicit use case would more helpful, i.e. what is the UX of the user story that can't be captured?

I'm really confused by this, instead of coupling B & C to A, I would move the code to "load A" into A.js and then have A.js update the "B.data" and "C.data". That way if the A.data changes for any reason the other components are automatically rerendered rather than trying to delegate

That's complexity increased, bad practice. Try writing it here in full let's see what you mean, but to me you have just increased complexity by a lot.

control from one component to another one. Even in the case shared, I would still decouple the data to render A from the component A. We have used a single class which contains methods like fetchData and hasInitialized for which the latter is a promise and the former resolves the latter.

This is now coupling the components too much. We want these to work without the other except for A.

Directly coupling the components together creates unexpected dependency trees which prevents the components from being reusable and allowing vue to rerender them correctly.

In fact you are missing the point, these are loosely coupled to the extend that each can be used and maintained without affecting the other. In fact you can drop any of them multiple times anywhere without writing any more code in the parents outside of <component-x />, no v-if, vuex to manage its state nor anything else.
I coupled them A to B and C just to demonstrate, I could have split this nicely or just count how many components have responded then continue when a certain expected number is reached (2 in this case) eg:
 this.$root.$emit('thruster-mounted') // in B and C
// instead of
 this.$root.$emit('thruster-1-mounted') // for B and 2 for C

// then count the responses and resolve once they are >= 2 in component A

Anyway, that's why I said Components Dependency Handling, this is desired and expected, but to be done in as little complexity as possible because the more complex it gets the more confusing it becomes.

Alternatively, I would even emit the event directly to the parent of A, B, and C, and not on the global scope, and let the parent decide if to render B and C, i.e.

I knew you were going to say this, but this is undesired. These components should not be controlled by anything else, hence I emphasised that the main component cares less what its kids do, they should remain independent. I want to be able to place them anywhere in the App and still make this same thing work. The moment you do what you are saying there, watch how everything breaks apart. But I can easily literally put components anywhere in the DOM tree without even flinching, and everything will just work. I can even have multiple copies of this and it will still work. All thanks to async ... await on lifecycles.

  <template>
    <a-component @rendered="showBandC = true" />
    <b-component v-if="showBandC" />
    <c-component v-if="showBandC" />
  </template>

What is it about A that in this case we would actually need to render before B and C renders.

We want each component to do unique work before it is mounted. But all components will only render when every other component has finished doing that work. That's the story here.
So good luck with state management and v-if's just to control this not to mention the actual data it will probably produce in the vuex store. You will end up having a lot of duplicate code written wherever the component is  used. Let's say you have another component that hosts A and C only and in a different configuration? You have to write those v-if's, vuex state management to make that work. Do you see the problem? let me illustrate:
  // component Z totally different from foo, so we can't make this a component for reuse
  <template>
    <a-component @rendered="showBandC = true" />
    <c-component v-if="showBandC" />
  </template>
 ...
computed: {
showBandB() { ...vuex ...,
showBandC() { ...vuex ...,
}

  // component Foo totally unique, probably has other things it does
  <template>
    <b-component v-if="showBandC" />
    <c-component v-if="showBandC" />
  </template>
 ...
computed: {
// ok you could mixin this, fair, but complex nevertheless
showBandB() { ...vuex ...,
showBandC() { ...vuex ...,
}

..... and soo forth
instead of just using the components without ever doing anything in the parents like so:
  // component Z
  <template>
    <a-component />
    <b-component />
  </template>

  // component Foo
  <template>
    <b-component  />
    <c-component />
  </template>

... and so forth

If there is stuff in the created() method, nothing prevents that from populating the store via a javascript class or using a store module. But the explicit use case would more helpful, i.e. what is the UX of the user story that can't be captured?

Remember what I said about state management littered everywhere? We don't want that coz managing these components means we will be managing a lot things elsewhere, which is very complex instead of what I just did. Besides, it won't do what I want this to do; only mount when each component has completed what it is supposed to do with very little complexity.

The idea is for Vue to respect async internally before going to the next hook function.

Sure that part makes sense, but I'm not sure why the example needs to be convoluted, why not just say something like this user story:
My component has both async beforeMount and async mounted, but the code in mounted is firing before the code in beforeMount is completed. How can we block mounted from firing before beforeMount is completed?

The point is that we want  things to happen before any of these components render and be usable without too much input outside of the components themselves. This is an actual thing I noticed I could have done better if this was available an app that we are making. I ended up writing code that has a lot of mixins, vuex and heavily coupled parents everywhere (using mixins) the components were used becoz this is missing. This is not some convoluted story, I am actually telling you what happened in a simple manner. We had to rethink how the UI was supposed to be designed and maintained. It got a little less interesting visually and a lot complex code-wise.
Do you see how many complex things you introduced into this simple setup that was just solved by that little async ... await feature in lifecycles?

@wparad

I.e. what happens when you attempt to unmount a component that hasn't finished being created, wow, that would be bad to be awaiting that still. Or destroying one that hasn't finished being mounted, I don't envy the implementor of that functionality.

This is where:

... requires a fundamental rethink/rewrite of the architecture to achieve, and can potentially break a lot of logic that relies on the synchronous nature of lifecycle hooks...

... part I believe was being mentioned by You. We need a way to handle these edge cases and probably more that this introduces. In other words our intents must work without crashing the app.
But if you look at the example I presented carefully, you will see what I mean. This could have solved a lot of things, without much code written anywhere. In fact our App could have been a lot better with a much small, defragmented and easy to grasp codebase if this were possible.
The thing about these kind of features is that you only see their importance once you hit a roadblock. I first came to this page when we had thought of many workarounds about this very example I just gave. I had not come to seek help, it was to lodge a feature request since we noticed it wasn't available in Vue.

I've been playing around with an idea to achieve dynamically imported global plugins and this seems like a possible solution.
Vue plugins are a nice way to abstract functionality, however, once you have many of them, they increase the size of your bundle.
For example, you might add a date plugin ( like moment or dayjs ) to help you format dates, but might only need this in 2 out of 20 components - it is dead code in the remaining ones.
So, the alternatives may be to use functions instead of plugins and import them in the files that you want, making use of code-splitting to address the bundle size issue, but this does not give you the flexibility of plugins and adds more boilerplate for the more complex cases.
So, I was thinking I could add a single global plugin, which allows you to register any amount of lazily loaded plugins as dependencies of components, with an api similar to this
export default {
    name: "Post",

    props: {
        post: Object
    },

    // List of plugins required for this component to work
    dependsOn: [ "date" ],

    template: `
        <div>
            <h3 v-text="post.title"></h3>
            <p v-text="post.content"></p>
            <span>$date.format(post.createdAt)<span>
        </div>
    `
}

// Plugin to make it work

const LazyPlugins = {
    install(Vue) {
        Vue.mixin({
            async beforeCreate() {
                if (this.$options.dependsOn) {
                    // Use require to dynamically load and register the plugins,
                    // if they havent been registered yet
                }
            }
        })
    }
}

However, in order for this to work properly, I would need a way to defer the instantiation of the component until this method resolves, so that I don't get type errors when rendering.
Is there a good way to accomplish this? Or a whole other solution to the problem

I've been playing around with an idea to achieve dynamically imported global plugins and this seems like a possible solution.
Vue plugins are a nice way to abstract functionality, however, once you have many of them, they increase the size of your bundle.
For example, you might add a date plugin ( like moment or dayjs ) to help you format dates, but might only need this in 2 out of 20 components - it is dead code in the remaining ones.
So, the alternatives may be to use functions instead of plugins and import them in the files that you want, making use of code-splitting to address the bundle size issue, but this does not give you the flexibility of plugins and adds more boilerplate for the more complex cases.
So, I was thinking I could add a single global plugin, which allows you to register any amount of lazily loaded plugins as dependencies of components, with an api similar to this
export default {
    name: "Post",

    props: {
        post: Object
    },

    // List of plugins required for this component to work
    dependsOn: [ "date" ],

    template: `
        <div>
            <h3 v-text="post.title"></h3>
            <p v-text="post.content"></p>
            <span>$date.format(post.createdAt)<span>
        </div>
    `
}

// Plugin to make it work

const LazyPlugins = {
    install(Vue) {
        Vue.mixin({
            async beforeCreate() {
                if (this.$options.dependsOn) {
                    // Use require to dynamically load and register the plugins,
                    // if they havent been registered yet
                }
            }
        })
    }
}

However, in order for this to work properly, I would need a way to defer the instantiation of the component until this method resolves, so that I don't get type errors when rendering.
Is there a good way to accomplish this? Or a whole other solution to the problem

what about triggering an event when all created hooks are finished? then at least you could add your custom listener to that event. This would be a non-breaking change and already alleviate the situation.
My use case is that often I want watchers not to trigger on initialization, which I usually solve by setting the initialized variable to true in the next trick after the created hook and rewriting the watchers to check whether the component is already initialized or not. This is cumbersome. But if I try to move that logic to a mixin I utterly fail, because there is no way to know when an async created hook finished.

HI guys, I jumped to this problem today and did a small trick to delay the life cycle hooks of Vue component. Note: use it at your owned risk.
I created a decorator like this:
export const AsyncHook = <V extends Vue>(options?: Options<V> & ThisType<V>) => (target: any): any => {

    //-- resolve injection for target

    const oldCreated = target.prototype.created || function () {};
    target.prototype.created = function () {
        ((this as any).injector as IInjector).initInstances().then(() => {
            oldCreated.call(this).then(()=>{(this as any).createdResolver();});
        });
    };

    const oldBeforeMount = target.prototype.beforeMount || function () {};
    target.prototype.beforeMount = function () {
        ((this as any).createdPromise as Promise<void>).then(() => {
            oldBeforeMount.call(this).then(()=>{ (this as any).beforeMountResolver();});
        });
    };

    const oldMounted = target.prototype.mounted || function () {};
    target.prototype.mounted = function () {
        ((this as any).beforeMountPromise as Promise<void>).then(() => {
            oldMounted.call(this);
        });
    };

    const newTarget = class extends target {

        private createdPromise: Promise<void>;
        private createdResolver: any;

        private beforeMountPromise: Promise<void>;
        private beforeMountResolver: any;

        constructor(...args: any[]) {
           super(args);

            this.createdPromise = new Promise((resolve) => {
                this.createdResolver = resolve;
            });
            this.beforeMountPromise = new Promise((resolve) => {
                this.beforeMountResolver = resolve;
            });
        }
    };

    //-- new target must inherit prototype from old target, otherwise there will be no hooks in new target
    newTarget.prototype = target.prototype;

    return newTarget;
};

use it like this
@AsyncHook()
@Component({})
export default class YourComponent{

     async created(){
         await DelaySome(3000);
         console.log("created");
     }

    async beforeMount(){
         await DelaySome(1000);
         console.log("beforeMount");
     }

    async mounted(){
         console.log("mounted");
     }

}

Output as expected: created > beforeMount > mounted

Output:
I'm setup hook
I'm beforeCreate hook
Bob is currently  undefined
computed hook is returning  undefined
I'm data hook

https://javascripter.space/questions/should-you-hold-off-on-moving-forward-until-the-asynchronous-task-finishes similarity?

authors: 464bb26bac556e85b6fd6b524347b103 AbdullaevTimur RashadSaleh ReinisV aliviadav athongintel baldychristophe breadadams cederron darren-dev emahuni fifman garyo gthomas2 hs-moosa javascripterV8 klausXR mzihlmann posva robob4him seanfisher sjmcdowall smolinari wparad yyx990803 zaken


text:
Provided values in mixin are not accessible

Version
2.5.21
Reproduction link
https://codepen.io/anon/pen/oJLdMN
Open the link and see the error message in dev console.
Steps to reproduce
Create two mixins with a provide object using Symbol as it's key field. Then assign these mixins to a component.
What is expected?
The child component can access two provide object without any error.
What is actually happening?
The child component can only access the last provide object, while the first one is undefined.

Diving into the source code, the reason of this issue is that Vue uses Object.keys to iterate over the provide object while merging mixins. However, Object.keys won't return Symbol keys. see the code.
Maybe we should use for ... in loop, which will iterate through Symbol keys correctly.

It doesn't seem to be related to Symbols but rather using provide in a mixin as this also fails:

var provideMixin1 = {
  provide: {
    foo: 'it is foo'
  }
}

var Parent = {
  mixin: [
    provideMixin1,
  ],
  template: '
<slot />
'
}

var Child = {
  inject: ['foo'],
  template: '
foo: {{ foo }} bar:
',
}

new Vue({
  components: {
    Parent,
    Child,
  },
  template: '<parent><child /></parent>'
}).$mount('#app')

I'm sorry that I got a typo...
It should be mixins rather than mixin, but the Symboled key still can't be treated correctly.
https://codepen.io/anon/pen/NeroQJ

This is addressed by #7926 (pending merge for next minor)

Ups, my bad, sorry!

authors: Tidyzq posva yyx990803


text:
fix(typing): relax $options type for TS2.6+

[x] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[x] It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
[x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[x] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
[x] New/updated tests are included

Other information:
TS2.6 introduces strict function variance. $options's type breaks variance check. Relaxing the signature solves this. (We need TS2.6RC to break existing code, this fix is tested locally)

Can this released as a patch now? the typescript@2.6.1 is released now.


text:
fix(plugin-markdown-math): incorrect import css path

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Provide a description in this PR that addresses what the PR is solving. If this PR is going to solve an existing issue, please reference the issue (e.g. close #123).

What is the purpose of this pull request?

[x] Bug fix
[ ] New feature
[ ] Other

Description

Screenshots

Before
After

Pull Request Test Coverage Report for Build 10985946226
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 58.636%

Totals

Change from base Build 10982335413:
0.0%

Covered Lines:
1168

Relevant Lines:
1794

💛  - Coveralls

authors: coveralls pengzhanbo

repo: vuepress/ecosystem


text:
fix queue 'supports_' methods with empty flags

The methods prefixed with supports_ in vulkano::device::physical::QueueFamily should use the contains method with queue_flags. This makes sure that if the tested flags are are empty, they are supported. This fixes a panic when for example: timestamping PipelineStage::TopOfPipe, PipelineStage::BottomOfPipe or PipelineStage::AllCommands where no flags are required for them to be supported.

Thanks again for the fix!

authors: Overpeek Rua

repo: vulkano-rs/vulkano


text:
Some shader parse refactoring and additions

This is needed for some future changes I'm working on. Spirv now returns slices of instructions directly, instead of iterators, and the reflected SPIR-V internal types receive a few additional items.

None.

Yeah but Spirv is more of a Vulkano-internal thing anyway. It's used for Vulkano's own reflection, and is only public because Vulkano-shaders needs it.


text:
[BUG] Vault changes after rename

Describe the bug
When changing vault name, the vault changes.
Expected behavior
After rename, the amended vault is still selected in Home View
-version 35

https://github.com/vultisig/vultisig-ios/assets/1700699/8b306b61-680b-4098-99f6-2850533eca3e
@realpaaao can you show me what are you expecting?

@enriquesouza It happens when going directly from home view into settings.
https://github.com/vultisig/vultisig-ios/assets/167348323/a472eed8-3eec-441e-990e-f81c9db4f4a8

It does not happen to me, maybe it is because I don't have as many wallets as you do.

Found it, if you have more than 2 wallets it happens

This is because the selected vault's name has been saved , but since the name get changed , so it doesn't match with the saved vault name

authors: enriquesouza johnnyluo realpaaao

repo: vultisig/vultisig-ios


text:
Menu Bar

Feature Request...
🤓Option to hide the MacForge menu bar icon would be nice please 🤓🙏

Yeah I'm pretty sure this can be done pretty easily.

This is live in 0.13.2


text:
pragma once in main file except in header file

ALEInfo:
Current Filetype: cpp
Available Linters: ['cppcheck', 'g++', 'cppcheck', 'g++']
Enabled Linters: ['cppcheck', 'g++', 'cppcheck', 'g++']
This occurs when #pragma once is in a header file (.h) in C++. I'm guessing that the issue is that the clang linter assumes that the file being checked is a main file (.cpp) when ALE is running on the current file. Is there a way to filter the linter's response based on file name and file type?

Moved to #392.

I finally fixed this one. I just needed to check the file extension for the open file and filter that one error out.


text:
Global variables

Is there any reason for us to use global variables, as opposed to buffer-scoped variables? I think buffer-scoped variables make more sense for our use case, and could be used to simplify much of the code.

When you queue a linter being run, the handler might be fired in a different buffer than the buffer you queued the linter from. For that reason, you need to map from the job ID back to the original buffer again. There shouldn't be more either global or buffer variables than are needed. Options should tend to be globals.

Fair enough, makes sense. And yeah, options should be global. I'll implement the PR I'm working on using globals, then.


text:
🔥 cleanup: remove setup.ps1 powershell script

The setup script is no longer needed as the installation process has been completed.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (3206660) to head (300aa60).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #491   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           30        30
  Lines          313       313
  Branches        82        82
=========================================
  Hits           313       313

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.