DOM updates being fed through args still lag about glimmer.js HOT 10 CLOSED

Also is there a recommended way to work around this so (automated) releases are possible?

from glimmer.js.

Would it be possible to do a reproduction here? https://glimmer-playground.netlify.com/

from glimmer.js.

Well, actually, because I have been banging my head against this wall for many many hours I released on was slightly lazy when opening this bug. Should have done more homework...

It seems that the fix I mentioned (merged Jul 11) is committed into the newest code but it is not part the code created by the ember new my-app -b @glimmer/blueprint with [email protected] as of today.

I don't know whether that's OK or not.

from glimmer.js.

@forbesmyester Apologies, I'm not sure if I understand exactly what the problem you're describing is.

Can you provide some more details on how to reproduce "DOM updates being fed through args still lag" and what version of @glimmer/application and @glimmer/component you're on? Thanks!

from glimmer.js.

for me, it's the distributed version with ember-cli that fail.

the tracked args are not updated properly in child components when args change.
the update apply after render update so the visible change are delayed to next rendering, as mentionned in another issue/PR that solved the problem.

if you try to use this experimental spa you'll see that look broken (routing with click twice, date-picker days are out of sync when navigating, counter act weird, ect) in fact that work, not as expected.

from glimmer.js.

Well the fix in @glimmer/component which was fixed on Jul 11, is still not included in glimmer when following the instructions on the front of the glimmer website.

npm install -g ember-cli
ember new my-app -b @glimmer/blueprint
cd my-app/ && ember s

The update() function still has no body in node_modules/@glimmer/component/dist/commonjs/es2017/component-manager.js

The effect of the bug is exactly the same as is described in bug #67, because it is that bug.

Package.json below:

{
  "name": "my-app",
  "version": "0.0.0",
  "description": "A brand new Glimmer app.",
  "directories": {
    "doc": "doc",
    "test": "tests"
  },
  "scripts": {
    "build": "ember build -e production",
    "start": "ember server",
    "test": "ember test"
  },
  "devDependencies": {
    "@glimmer/application": "^0.7.2",
    "@glimmer/application-pipeline": "^0.8.0",
    "@glimmer/blueprint": "^0.5.0",
    "@glimmer/inline-precompile": "^1.0.0",
    "@glimmer/resolver": "^0.3.0",
    "@glimmer/test-helpers": "^0.30.0",
    "@types/qunit": "^2.0.31",
    "broccoli-asset-rev": "^2.5.0",
    "ember-cli": "^2.14.0",
    "ember-cli-dependency-checker": "^2.0.1",
    "ember-cli-inject-live-reload": "^1.6.1",
    "ember-cli-sass": "^6.2.0",
    "ember-cli-uglify": "^2.0.0-beta.1",
    "qunitjs": "^2.3.3",
    "typescript": "^2.2.2"
  },
  "engines": {
    "node": ">= 4.0"
  },
  "private": true
}

from glimmer.js.

Okay, so the bug has been fixed in 0.8.0 but you’re reporting that the issue is that the blueprint hasn’t been updated, is that right?

from glimmer.js.

Pretty much.

At the time I had spent a day debugging and finding what had happened. I could see it was in another repo and was concerned it had got lost or something had got stuck/lost/broken in the release process as the bug seems quite big/fundamental and very old.

So I was also joining up the repo's/bugs for tracking purposes as the repo move (presumably) destroyed that part of the (bug) history.

from glimmer.js.

@forbesmyester Got it, thank you. I agree it's a big problem that we need to prioritize—just want to make sure there aren't even more bugs in the internals that I need to investigate.

from glimmer.js.

I just published @glimmer/[email protected] which should fix this.

Sorry for the delays.

from glimmer.js.