iizunats / iizuna Goto Github PK

replacing this.__options.selector with this.selector

like

this.identifier or this.getIdentifier()

Is your feature request related to a problem? Please describe.
If you want to assign several different events to the same element, you currently have to decorate the method several times.

Describe the solution you'd like
I propose the following syntax:
click keyup submit
instead of:

@EventListener('click')
@EventListener('keyup')
@EventListener('submit')

Is your feature request related to a problem? Please describe.
The current functionality of the Template is more than limited. We need a simple solution for the given problems:

1. Template string expressions may confuse server side rendering (because expressions may look he same there)
2. Reusable components (with templates) that are used multiple times on one page may cause the server to render the same template tag multiple times
3. Business logic and templates should stay decoupled from one another. We don't need e.g. rendering conditions at this point.

Describe the solution you'd like

• 1. We could allow the user to define the expression syntax themselves. Or we could switch completely to another approach for template hydration.
  • 2.1 We could allow the components to have templates inside of them instead of referring by the id of the template tag. That wouldn't solve the problem that the same template is used multiple times.
  • 2.2 We could also allow to pull templates from external files. CMS could then implement an API which return the template with expressions and the CMS could then use this API internally to pre-hydrate the same template for server side rendering.
• 3. IMHO the creation of new elements should not happen based by attributes of HTMLElements.

Every class should then extend of this class. so its a pretty big game changer.

Will be released in the next major!

Describe the solution you'd like
It would be nice to configure some templates to be persistant to allow faster page loads when the user already had downloaded the template file.
We should also allow additional configuration in cases when an error or soft 404 is shown instead of the template.

Is your feature request related to a problem? Please describe.
The folder structure is currently not scalable. For each new feature, a test file is placed in the same folder, which doubles the size of the folder and the clarity is lost.

Describe the solution you'd like
Die Ordnersturktur könnte in zukunft z.B. so aussehen:

• .github
• src
  • ...
• test(s)
  • unit
    • ...
  • bdd
    • ...

Is your feature request related to a problem? Please describe.
it is possible to include functionality to specific elements that would break if placed on child elements.

Describe the solution you'd like
Add limit selector to component decorator. If an element does not match the selector, show a warning in the console.

Is your feature request related to a problem? Please describe.
To give potential users a better idea of ​​whether the framework is right for them, they need a list of all supported browsers.

Describe the solution you'd like
A table with supported browsers in the README.md and an updated list of browsers that are used to test the framework.

Is your feature request related to a problem? Please describe.
There is currently no consistent approach for singletons in iizuna. dependency injection like angular already does it (as argument inside of the constructor) would solve the problem

Describe the solution you'd like
it would be nice if i create a class and define a constructor property of a component class as this class
to have an instance of this class injected into the component:

//example of simple dependency injection
class ClassName{}

class Component {
    constructor(private object:ClassName){
        console.log(object);//should log a new instance of ClassName into the console
    }
}

//example of simple dependency injection with singletons
@Singleton()
class ClassName{}

class Component {
    constructor(private object:ClassName){
        console.log(object);//should log everywhere the same instance of ClassName into the console
    }
}

Describe alternatives you've considered
We could also implement a Helper Class or a Factory (which we should do anyways) to get an instance of a specific class.

Expected behavior
When there is a variable like this: ${object.name} i expect it to render the "name" property of the object.

Is your feature request related to a problem? Please describe.
If several components build on one another, they must be executed in the correct order.

Describe the solution you'd like
I was either thinking of a simple number indicating the priority, or possibly a queue of components.

Additional context
Things like EventListener (e.g. resize) must also be taken into account during implementation.
If a component omits a height during initialization that is set by another component, this sequence must also be observed for other triggers.

Is your feature request related to a problem? Please describe.
There are always problems when it comes to testing complex components.
We should think about a ways to test and debug these.

Describe the solution you'd like

• There should be a simple way to mock a component for testing porposes
• We need a "development" build like process which then generates an additional output inside of the Browser console (or somewhere else?)