@ngx-form/element
Angular 2+ module to dynamically create previously configured html form element using
config
attribute.Commit Versioning
Documentation
http://ngx-form.wwwdev.ioInstallation
To install, run:npm install --save @ngx-form/element @ngx-form/interface
Usage
import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { ReactiveFormsModule } from '@angular/forms';
// internal
import { FormElementModule } from '@ngx-form/element';
import { InputComponent } from './input.component';
import { SelectComponent } from './select.component';
@NgModule({
entryComponents: [
InputComponent,
SelectComponent
],
imports: [
// external
BrowserModule,
ReactiveFormsModule,
// internal
FormElementModule.forRoot({
elements: [
{
name: 'input',
component: InputComponent // your component here
},
{
name: 'select',
component: SelectComponent // your component here
}
]
})
],
declarations: [ ]
})
export class ExampleModule { }
Style guide
Angular style guideGIT
Commit
Versioning
Semantic Versioning 2.0.0 http://semver.org/Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
FAQ
How should I deal with revisions in the 0.y.z initial development phase?
>The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.
How do I know when to release 1.0.0?
>If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.