DOM updates being fed through args still lag

[forbesmyester]

Hi,

I'm still being hit by an issue that looks very much like https://github.com/glimmerjs/glimmer-component/issues/66

Manually hacking fix in seems to have solved the issue.

Opening issue due to the issue no longer being part of the history (as it's moved to this monorepo) and maybe the fix has been lost somehow (or maybe we need a new release).

[forbesmyester]

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

[chadhietala]

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

[forbesmyester]

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 ember-cli@2.16.2 as of today.

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

[tomdale]

@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!

[c0urg3tt3]

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.

[forbesmyester]

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
}

[tomdale]

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?

[forbesmyester]

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.

[tomdale]

@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.

[rwjblue]

I just published @glimmer/blueprint@0.6.0 which should fix this.

Sorry for the delays.