Closed vivekimsit closed 8 years ago
Yeah, you are right. NX uses the v0 spec (with document.registerElement), because it is supported in chrome at least (all other browsers are polyfilled with MutationObservers). I will migrate things internally to work with the v1 spec when browsers start to support it. It will be a small change without breaking anything.
Thx for the warning.
I would like to make contributions to it can you please refer to me some prior reading before getting started?
Cool (: Do you mean contribution regarding this issue or NX in general? I am writing a new part of the docs for contributors right now. In them meantime I will look for some resources for you today.
No, I want to contribute in general, meanwhile you can close this issue marking it as feature.
You can start by reading the Docs. I started writing a blog series about the difficulties while writing NX. It is not very specific, but it should help (next article is out on Tuesday).
I will think about a nice task for you before posting heavier things. Do you have any favorite topics in web dev?
Thanks, not any particular interest but I have Angularjs experience. I was thinking to write the utlity functions for repeated logic eg: 'isFunction' etc.
For simple logic I don't think we need that. util.isFunction(fn)
is not a lot shorter than typeof fn === 'function'
. For longer checks it could be useful though. Also improving the error messages is something I plan to do, but it's not a very exciting task.
As a longer project you could make and maintain a new middleware, which NX is still missing (like animation or form validation). If you are interested I can help you get started with that. A middleware is just a separate pluggable function, so you can start on this without much knowledge about how NX works.
its not about long or short, ideally every piece of information should be in just one place. Having said that I can start with form validation, it would be good if you can impart some knowledge to me and then create a new feature request to track down the progress easily.
Sure, but I try to avoid shared utility libraries because of the middleware system. Middlewares work best if they are focused and have few or no dependencies. After the alpha I plan to split all the middlewares into separate repos for more flexibility. I will be on vacation for the weekend. Lets get back to this and the form validation middleware on Monday, if its okay for you. Have a nice weekend (:
Sure thing, bon voyage :+1:
Hi!
About the form validation middleware:
validation: require('validation')
About form validation in general:
About putting this together:
The validation API applies css selectors to invalid elements and prevents their parent form submission. I think you should extend this functionality, by choking every event caused by user input if the input is invalid. (with stopPropagation(), and without
preventDefault()`). This way we can prevent any handler and data binding logic form triggering on invalid events (as they both rely on event handlers, triggered by events)
This means it works nicely with the existing middlewares, but can be used without them too. I currently have no idea of how to choke the events, but I am investigating it.
I will add some pseudo code soon, it should explain it a lot better. What is your opinion, do you have any ideas, is it unclear/too though as a start?
Hi,
Thanks for the guidelines the middle ware concept is somewhat new to me but I am sure its worth reading it. Having said that I will create a new feature request for the form validation and can you please set up the gitter chat for generic discussion like these?
Hi,
Hope you are doing good, I looked up the docs and the MDN links (I may need to re-read them :)). I tried to get some inspiration from angular form validation and figured out some simple API, its in draft phase so feel free to comment.
https://gist.github.com/vivekimsit/12348b91687833d1bb02a7b78c032719
Hi!
I commented on your gist (:
I was just going through custom element specs here at MDN and it says its deprecated.