RE: Explicit dependency on observer

[vivekimsit]

Given the example below:

const component = require('@nx-js/core')
const observe = require('@nx-js/observe-middleware')
const attributes = require('@nx-js/attributes-middleware')

component()
  .useOnContent(observe)
  .useOnContent(attributes)
  .register('attributes-comp')

I was wondering if attributes already depends on the observer then why use it again?

[solkimicreb]

Middleware dependencies are not automatically resolved. They throw a warning if the required middlewares are not found, but you have to add every middleware by hand. They are similar the npm peer dependencies. Try to remove the .useOnContent(observe) line and see the resulting error.

There are some pretty big changes coming, but I don't plan to change this significantly. Do you think it should be handled differently?

[vivekimsit]

I think this is more pragmatic:

component()
  .useOnContent(attributes)
  .register('attributes-comp')

Because I don't have to think about dependency's dependencies. We need to think how we could achieve that, probably some factory function could do the trick?

[solkimicreb]

It would be doable with something like middleware.inject = arrayOfMifflewareFunction, especially after the next update.

Here is the big picture however.

Middlewares are the deepest building block and standard middlewares are not really meant to be added by web developers. They are exposed for advanced users and framework developers.

Components are one level above middlewares. They are essentially the combinations a config object and a list of middlewares and they are meant to be used by the web developers.

For example you would rarely write

component()
  .useOnContent(observe)
  .useOnContent(attributes)
  .register('attributes-comp')

by hand, you would rather write

components.app()
  .register('my-app')

as it already includes the attributes middleware. My goal is to have a ready made component for every common combination of middlewares. After looking at the docs, I feel like I really miscommunicated this 🙁

In the next version I even plan to remove middleware inheritance, so the components would really have to list all of the middlewares it uses. My goal with this is to provide a very quick way of determining exactly what functionalities are available in the component and to provide more clarity.

Take a look at the following example (full source code of components.base from the next version).

import { component } from '@nx-js/core'
import { observe, interpolate, attributes, style, animate, ref,
  flow, bindable, bind, events } from '../middlewares'

export default function base (config) {
  config = config || {}

  return component(config)
    .use(observe)
    .use(interpolate)
    .use(attributes)
    .use(style)
    .use(animate)
    .use(ref)
    .use(flow)
    .use(bindable)
    .use(events)
}

Without any docs, you can tell by a quick glance what functionalities will be available inside a registered base component.

Splitting middleware injection between components and other middlewares would obscure this. This is only my way of seeing this however. It would be really nice to have some more people involved and to hear more perspectives. Do you play around with NX, did this cause you to write some extra boilerplate?

Thx for the issue btw, nice to see you again 🙂

[vivekimsit]

Yes, its been a busy time for me switching jobs and all. I have been playing with a couple of frameworks lately to get more hold of the best practices.

Most probably I will be free after this month and could give more time here. I am still wondering how to be an active contributor since most of the work you do is in stealth mode unless its releases :)

I really want to know you thought process and how you make your decisions on API and learning etc.

Thanks,

[solkimicreb]

That's actually a very valid point, I have a lots of unpushed code all the time. I think the main reason is that I like to experiment before doing a change with a large amount of discarded/failed attempts and I try to avoid pushing them.

I will try to improve on this, it is some really valuable feedback. I will let you know when I clean up the current mess and I am ready to be transparent. If you find anything that you really like about other lesser known frameworks I would be glad to learn about them.

About API decisions. I usually make (not functional) dummy apps and experiment with different APIs on them until I am satisfied with the feel of them. I usually make my decisions when I have some time to relax (not while programming).

Good luck with your new job (: