elm-aframe
elm-aframe copied to clipboard
halfzebra
A-Frame DOM elements incorrectly updated by standard view function
It looks like Elm's runtime updates the A-Frame DOM elements incorrectly when the output from the view function changes.
In the linked example, the position of a canvas element is being updated instead of the position of the box, as would be expected. https://ellie-app.com/349DTf7sRa1/3
I'm not sure how elm-aframe would resolve this, but it's nevertheless a problem.
A change was made between A-Frame version 0.6.1 and 0.7.0 that has caused this behaviour. Until this is fixed on the A-Frame side (if it ever is), users of this Elm library can use the latest working version of A-Frame, built slightly before the 0.7.0 release: https://github.com/aframevr/aframe/blob/3f116d9e008b67eff0f743da449e902f13e1d80c/dist/aframe-master.min.js
This build of A-Frame still supports glTF 2.0 models.
Thanks for figuring this out @nmsmith. I used git bisect to try and track down the first A-Frame commit where my basic elm-aframe example fails (I think for the same reason?). Looks like it's 412d1620. Here's the commit message:
Moves canvas initialization logic from a component to the scene. This handle the case when calling enterVR before the renderer is initialized and also moves the canvas and renderer initialization before assets load (it's not a component anymore). This is a prequesite for a loading screen / spinner (#2985)
I'm planning on looking into this in detail at some point.
@dkmg24 That's right :)
I found the same commit, and opened an issue in the A-Frame repo many months ago. I proposed a solution: it's not been tackled by anyone.
There is a second problem with updates, which I logged in this A-Frame issue. The contributors declined to fix it without justification. Perhaps someone else can prompt for that justification.
Awesome, thanks for championing this cause! :smile:
I added my support to your response on the second issue #3469. I'm going to look into the first issue #3460 now and see if I can fix it.
It seems that the core A-Frame maintainer is still hostile to any kind of proposal, so I don't think this is worth any more effort. I'll leave the issue open in case you still want to continue pursuing it.
Despite the claims made on its website, A-Frame is not declarative. It relies heavily on self-mutating local state for its entity component system, so even if we're able to get it working with Elm, we'd have to avoid using components.
Future efforts on bringing VR to Elm should probably involve building an Elm package directly on top of WebXR (once early releases become available) and using existing packages like WebGL, elm-geometry, and elm-physics.
It seems to be fixed in a-frame v1.0.4. Just change the version of a-frame from 0.8.0 to 1.0.4 in the scene suggested in the description and the box will move instead of a canvas: https://ellie-app.com/QQdVpNWBKPa1.
Also, I've updated the example to Elm 0.19 + my fork of elm-aframe (the one updated for 0.19), and the issue is no more the issue: https://ellie-app.com/b7nprw32s4va1