nx-js / framework Goto Github PK

I was just going through custom element specs here at MDN and it says its deprecated.

This error occurs here, and I don't know why as it works as expected. There should be more defensive code.
https://github.com/janat08/blockrazor/tree/createButton

Are there any examples around? I have been using Nunjucks but I was looking for a client-side routing solution and this framework hits the spot.

I need to clarify some questions:

1. Is it possible to install it using Bower package? or only NPM?
2. Why does it include GA module?
3. And takes 300kb in size?
4. How soon IE11 support can be added?

I see that the support for the following clipboard events are missing:

http://www.quirksmode.org/dom/events/cutcopypaste.html

Would you support some tests for me ? I think It is easy to understand your intention.

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?

CHANGES IN THE NEXT RELEASE

• Lazy component loading with the nx.load(compName, loaderFn) function.
• Async component processing for heavy components with the heavy boolean component config property (It uses requestIdleCallback when it it supported with a setTimeout fallback).
• ES6 module syntax and tree shaking support.
• Total refactor of the core with support for custom components v1 (v0 and mutationobserver as fallbacks).
• Various performance improvements (especially on non chrome browsers).
• $process and $allow middleware metadata properties, that control which node types can be processed and which ones should throw an error when encountered.
• The same $process and $allow metadata properties for custom attributes.

FEATURES SCHEDULED FOR LATERS

• Cascading styles for quicker animations with less code (animate-middleware)
• Scroll middleware for scroll routing and scroll-into-view detection
• Limiters and filters for data-binding (bindable-middleware)
• Shadow DOM flavored slot styling for scoped styles (render-middleware)
• Dynamic and one time validation with a new validator util

The list is continuously edited. New ideas are added to it and when a feature makes it into a release it is deleted from here. Feel free to post feature suggestions in the comments! 🙂

The package says in needs webpack, and I saw some webpack calls inside nx-beta download, would it work with meteor?

NX seems like an awesome idea, but i see no recent activity here,
is this a live project?

tries to access state.history.params, and while it's defined before and after the access, it will fail if there's another router being used.

typeNX.js:2385 Uncaught TypeError: Cannot read property 'params' of null
    at syncStatesWithParams (typeNX.js:2385)
    at eval (typeNX.js:2352)
    at SmartWizard._setURLHash (/node_modules/smartwizard/dist/js/jquery.smartWizard.js:544)
    at SmartWizard._transitPage (/node_modules/smartwizard/dist/js/jquery.smartWizard.js:460)
    at SmartWizard._loadStepContent (/node_modules/smartwizard/dist/js/jquery.smartWizard.js:404)
    at SmartWizard._showStep (/node_modules/smartwizard/dist/js/jquery.smartWizard.js:354)
    at SmartWizard.init (/node_modules/smartwizard/dist/js/jquery.smartWizard.js:121)
    at new SmartWizard (/node_modules/smartwizard/dist/js/jquery.smartWizard.js:88)
    at HTMLDivElement.eval (/node_modules/smartwizard/dist/js/jquery.smartWizard.js:638)
    at Function.each (modules.js?hash=fa65c5222d37ccb63afe46b49c068a2095600027:6549)

Trying to hit https://nx-framework.com/ gives me 402 Error.
I think the popularity of the app grows every second and thus you will need to add more quota to your account :)))

Regrads,
@Stradivario

https://www.webcomponents.org/introduction
You may wish to try and make the cut into the list at the bottom.

Is this project dead?

I was just reading about NX - found it an interesting framework. However, from the docs, I could not find out if it's possible to get a reference for the DOM element the component is managing, for example if I want to do specific changes to the DOM (outside the framework) using jQuery. Could you provide an example of using NX along side of jQuery?

As you may know some browsers are not yet supported, because of the use of unpolyfillable ES6 Proxies in this helper library. This is a proposal to add a fallback for those browsers.

The NX core sets up hooks (middlewares) on DOM element attachments. Other then this it does a few other things, like transforming the state object into an observable object (this is where Proxies are used).

I plan to move everything other then the hook definitions out of the core into separate middlewares. I would move the code using the Proxy into a middleware called observe and create an alternative legacy-observe middleware that uses getters/setter instead of Proxies for data binding.

This way, the only thing you would have to do to achieve wider browser support is replacing comp.useOnContent(observe) with comp.useOnContent(legacyObserve) in the app component you use. The limitation of using legacyObserve would be not being able to bind on getters/setters and expando properties (this is a big one.) These limitations are present with all current data binding techniques that I know of others than the Proxy method.

What is your opinion, is it understandable?

What's the difference between nx-framework and react/vue ?

Based on the line:

https://www.html5rocks.com/en/tutorials/webcomponents/customelements/#unresolvedels

I would suggest to have a global style,

 :unresolved {
    display: none;
  }

something like https://docs.angularjs.org/api/ng/directive/ngCloak

wdyt?

NX relies heavily on peer dependencies and semver internally, because of its modular nature. If you find issues with the npm install please post them here. Thx!

Ive been on the lookout for a reactive first library that can handle jquery, and I think it's a major and great quality in a library especially where js fatigue is concerned.

Hi,
I'm playing with the framework and trying to port some apps I have to nx. So far I didn't have any issues, but recently I've been trying to replicate a custom component (a component I created for another framework) with NX and failed.

The component is what I call a "repeater". Basically, you drop the component into the page, assign an "item template" to it and bind the component to an iterable source (an array, for example).

The component then iterates the source and renders each entry using the template. This is the easy part since I only have to use the @repeat attr and I'm done.

Now, the component has to have two other functionalities:

• Be able to delete a row.
• Be able to add a row.

In my component, I handle the first by deleting the corresponding item from the array, and the second by firing an event and on that event adding the item to the array (I'm doing that because I don't know beforehand the type of item I would need to add). But here I don't have access to the binded property inside my component... How should I handle this?

The next release will include several breaking changes to the core. It aims to make the initial learning curve smaller and to simplify and speed up the core. Apart from the features mentioned here, I plan to add the following changes.

The component.useOnContent method will be removed

Instead only component.use will remain and middlewares behavior will be configurable with the middleware.$process array. It may contain code for COMPONENT, ELEMENT, TEXT and COMMENT nodes.

Take a look at the following snippet.

nx.component({root: true})
  .useOnContent(interpolate)
  .use(setup)
  .register('interpolate-comp')

function interpolate (node, state) {
  if (node instanceof Text) {
    node.nodeValue = node.nodeValue.replace(/\${(.+?)}/g, (match, prop) => state[prop])
  }
}

function setup (comp, state) {
  state.message = 'Hello World!'
}

It will turn into the following after the change.

nx.component({root: true})
  .use(interpolate)
  .use(setup)
  .register('interpolate-comp')

function interpolate (text, state) {
  text.nodeValue = text.nodeValue.replace(/\${(.+?)}/g, (match, prop) => state[prop])
}
interpolate.$process = [nx.types.TEXT]

function setup (comp, state) {
  state.message = 'Hello World!'
}

By default a middleware will only process the component node and non of its content. It moves complexity from the user to the contributors and middleware developers.

Middleware inheritance and the isolate config will be removed

Middlewares will no longer be inherited from ancestor components. Instead every component will have full control over what middleware it uses.

Take a look at the following snippet.

nx.components.app()
  .use((comp, state) => state.name = 'Bob')
  .register('app-comp')

nx.component().register('my-comp')

<app-comp>
  <my-comp>${name}</my-comp>
</app-comp>

In the current version this displays ‘Bob’, but in the next version it would display ‘${name}’. The reason is that my-comp wouldn’t inherit the interpolate middleware from app-comp.

Instead of relying on middleware inheritance the next release will introduce the base component which includes all of the important middlewares. It will serve as a base for most of the current components too. The above example could be rewritten as below with the next version.

nx.components.app()
  .use((comp, state) => state.name = 'Bob')
  .register('app-comp')

nx.components.base()
  .register('my-comp')

<app-comp>
  <my-comp>${name}</my-comp>
</app-comp>

This makes components more modular an easier to maintain as they take full responsibility of their behavior.

The this context in middlewares will be changed

Previously the this context inside middlewares was the currently processed node instance - which was also the first argument. This will change. The this context will always be the parent component instance (a web component). This means that for normal component middleares nothing will change. Content middlewares will get a reference to the parent component through the this context though.

To stay consistent, the this context will be set to the current component in every callback (attributes, observed functions, etc) too.

State boundaries will be reworked

State boundaries doesn’t always match with component boundaries in NX. For example the repeat attribute may add inheriting states to non component elements.

Handling state boundaries was a big hack, which was hidden by the attributes and props middleware. The next release will change this. The middleware.$boundary boolean prop will indicate that the middleware is a boundary middleware. NX injects the context/parent state into boundary middlewares on state boundaries instead of the new state. You probably won’t have to use this, but it makes developing complex middlewares easier for maintainers.

Many middlewares will be reworked

Most middlewares will be reworked form content to component middlewares (meaning that they will have middleware.$process=[nx.types.COMPONENT]). If all goes well, after the change only the attribute and interpolate middlewares will process content. Everything else will run only once on the component instance.

This removes a lot of unnecessary work and speeds up NX.

Does anyone experience issues with the editable examples not loading sometimes?

These are the changes I would like to happen before NX beta is released. In my opinion the beta should be as stable as possible to let us focus on bug fixes and documentation improvements. With a good pace the below changes should take around 2-3 months. What is your opinion? Would you like to see a stricter roadmap with rough deadlines?

Framework changes:

• form validation middleware POSTPONED
• transition/animation middleware DONE
• change Custom Elements polyfill to a subset of the official v1 polyfill POSTPONED (native implementation of type extension is buggy)
• Shadow DOM support (requires changes in core and the render middleware) DONE
• Scoped styles support DONE
• optimize the nx-compile and nx-observe helper libraries for speed DONE
• determine a list of officially supported browsers with exact versions
• get 100% test coverage with all supported browsers
• setup a linter

Small fixes and refactors:

• refactor core and all middlewares one by one: main goal is speed and readabilty DONE
• fix all reported bugs (naturally)

Docs and utilities:

• NX-CLI for project seed generation
• complex example apps and walk throughs written in NX IN PROGRESS
• home page cleanup and public release for contributors (the home page is an NX app)
• documentation for contributors
• separate, short API documentation instead of 'cheat sheets'

What comes after the beta:

• unofficial API freeze, breaking changes will happen only if unavoidable
• release a distributed version of NX, where every middleware is in its own repo (something similar to what Express is doing)