DOM node attribute changes not caught by handler

[revintec]

using nx beta 2.0.0 downloaded from https://nx-framework.com/install,
running on Mac OSX 10.10.5, Chrome 60.0.3112.113 (Official Build) (64-bit).
both of these are the newest versions as of writing this.

minimal code to illustrate the problem:

<fs-browser address="old"></fs-browser><script>
  let node;nx.components.app().use((n)=>{
    (node=n).$attribute("address",(address)=>console.info(`address changed to ${address}`));
  }).register("fs-browser");setTimeout(()=>node.setAttribute("address","new"));
</script>

console output when running the above example was: address changed to old and nothing more.
why changes made to the attribute is not caught, am I missing something here?

---

P.S.: nx is the best framework I've found so far, Vue has too many "edge cases". but development is too slow for this project, a lot of promised changes seems missing, so I'd like to work on this project to speed things up. what I'd like to do first is to restructure the project as it seems to scattered to me:
I'd like to make a new branch to nx-js/framework, and make every middleware
(which are in their individual repos, most of them can be made into in a single file)
a separate file inside nx-js/framework/middlewares, and move in other dependencies too.
I think by doing this, it allows easier collaborations and will speed up development, in the same time not sacrificing modularity too much. is this ok to you?

[solkimicreb]

Hi!

I will answer the PS and check the issue only later if that works for you 🙂 Yes, I promised a lot and failed to deliver recently, but I do not want to ditch the project. This was my 'learning framework' and I think it can be really felt in the way I handled things here. Currently I am making a stack for React (Easy State and Easy Params are ready so far if you are interested). After I am done with that - which should be in a month (this time really 🙂 ) - I want to turn back to NX with a lot of new experiences. I think these are the most urgent issues:

• As you mentioned - moving the project back to a mono-repo would be good. Currently I think we should use the Babel approach and make a Lerna mono-repo on Github, while keeping the modular nature on npm.

• Testing, coverage, countinuous integration, linting and code commenting are the very next on my list.

• I have a LOT of uncommited local code for NX, I plan to merge them during these too. (Biggies are probably ES6 modules, complete middleware system rework with the removal of useOnContent and data-binding rework).

• I think that the community is shifting towards global state stores and that we should follow too. I really want to add global stores and I think I messed up the params middleware. Params should be only allowed in global stores - like in React Easy Params.

• Would also like to solve the implicit dependecy issue with the middlewares. By this I mean that they are building on one another with an own dependency injection mechanism use. DI should be as simple and explicit as possible, I don't want to build the next Angular DI.

After these we could start adding new features 🙂 In the next month I can't promise to put much work into this, but after that I can join.

Would you like to get started with these, what are your opinion about them? I will try to clean up my unpushed code and put it on a branch - after the mono-repo is done - for review. I would be really grateful for a buddy on this project 🙂 Issue checking is coming in the next comment.

[solkimicreb]

It seems to be a lot of separate issues to me.

• state.field is correct to be an array at the first log. A dynamic Proxy tree is built and maintained on demand instead of creating Proxies on set operations. Instead of wrapping state.field in a Proxy right away the library waits until it is used in a reaction (a function that needs to rerun when it changes). This function is the @{field} template in the view. Until the view is interpolated for the first time state.field has no reason to be a Proxy. Did you experience a bug because of this or was it just a surprise for you?

• Manual attribute changes with native setAttribute are not picked up. The reason is when you do something like this: setAttribute('@hide', 'prop') it is really mind bogging. I figured this is more bug prone than flexible, but it could be improved in the future.

• ${} operates in a non-observing mode. It interpolates only once, so there is no need for Proxies here. @{} introduces transparent reactivity, in this mode Proxies are necessary. What you experienced was normal. Did it cause some bugs?

I hope these helped, thanks for the issue!

[revintec]

Hi, thx for the timely reply, I'll put the P.S. part first as it's more relevant:

1. the "I do not want to ditch the project" is all I, as well as all the other users I think, needs to hear, and your timely reply backs it. seeing almost no activity in almost half a year really makes me worry if this project is dead because of the lack of stars and forks, if so it's really a pity. and thx for the activity update, however I don't like react, angular and things alike, because they're too complex and introduces too many new concepts and grammar, I'd rather use something like Vue, but nx seems more elegant because it eliminates a lot of edge cases(notably Vue.set(...) among others), is there other frameworks like nx or Vue that you'd like to recommend?
2. I'm really interested in this project, actually I already began to port my JavaFx project into this one, so when you come back to this project, do let me know. you can assign me some minor works to help you speed up the nx project at that time.
3. I didn't invest too much time on Babel or Lerna, so it's not for me to judge, but if you think it's OK, then it's OK to me, which also covers my thoughts regarding CI and TDD.
4. I personally don't like to keep a "LOT" of changes uncommitted :) looking forwarded to nx 1.0.
5. I haven't used global stores too much, but it seems a good idea in general.
6. to sum it up, I'd really like to be a part of a great project like nx. I'm a backend developer, and HTML5 is always my hobby, I learned a lot myself over the years, though I may not be as good as a professional frontend developer. I may start slow but I think I'd do better as I become more familiar with nx.

now about the issue part, long story short, I made a mistake...
only one problem remains and I've edited the original issue to reflect this:
how can I trigger node.$attribute(...) callback outside the nx code?

the other parts of the problem is caused by me: I'm refactoring the code, and moved the reaction function to a callback by mistake, so it stopped working. the object got from a Proxy inside a synchronous reaction function call is Proxy, which is exactly what I expected. sorry for the false alarm.