Some words

[promontis]

Hi Kevin!

First of all, thanks for this library! I can see that you spent many hours working on this and I have a feeling - looking at the stars and such - it is a much overlooked library. Just wanted to say thanks for all the hard work and I get what you are trying to do.

It is weird that this isn't pushed a lot more, especially with the whole micro-frontends popularity and people realising that maybe doing full blown micro-frontends (distributed apps) is a bit overkill but the whole modularization and autonomy is much needed.

I also love the added React hooks! The composite UI is also wonderful!

What I like less is the lack of Typescript. I have seen https://github.com/KevinAst/feature-u/pull/34 and I really like the initiative. I do understand you decision to decline the PR... btw, do you still have the same feeling of lacking time? I don't think this is a deal-breaker for me; I can easily use the typings from that PR in my own projects. Also, if I have the time, I could push those typings to NPM via @types.

What I also like less is defineUse. I haven't really used feature-u, just merely following the tutorials to see if it fit my needs (which is probably does), but I kept asking myself why not provide instead defineUse. Also not a deal breaker btw :) just putting it out there.

All in all, I can't wait to start using it in my project! If it all fits well, I'm also going to write a proposal to use it at the company I work with.

[KevinAst]

Hello Michel,

Thanks so much for all your kind words.

I agree with you 100% regarding the micro-frontends similarity. From a "app logic" decoupling perspective, Feature-Driven Development (FDD) has a lot of common goals to the Micro Frontend strategy, without all the dependency issue headaches.

I am a big proponent of FDD, especially for "large-scaled projects". In my experience this approach scales very well.

Have you had a chance to look through the feature-u presentation? I have come to conclusion that feature-u is something that has to be seen to fully understand.

The most exciting part of feature-u (in my opinion) is it's ability to autonomously inject UI content (through cross-feature composition). This is what I say "has to be seen" ... it is shown at time 53:16 (in the video).

Regarding defineUse ... naming stuff is always hard :-( I understand where you are coming from, regarding provide, and trying to wrap you head around a new utility. My reasoning behind the terminology is that the three built-in fasset directives (define, use, and defineUse) are somewhat inner-related. The best explanation of this is the docs section on fassets recap: Push or Pull.

I do appreciate your enthusiasm! As a word of caution however, you may have guessed that I have somewhat "moved on" from this project. It's last update was February of 2020. I do think the code base is solid, but I would most likely be reluctant to work any enhancement requests. Obviously, the source is available to fork ... but I just wanted you to be aware of my situation.

I am actually retired, and have the freedom to move technology stacks (just for fun :-) I have become a strong proponent of Svelte, and am working on several utilities in that domain.

Thanks again for your remarks, and keep me posted on your usage of feature-u. You can find my email on my web page (linked in my github profile).

[promontis]

I do appreciate your enthusiasm! As a word of caution however, you may have guessed that I have somewhat "moved on" from this project. It's last update was February of 2020. I do think the code base is solid, but I would most likely be reluctant to work any enhancement requests. Obviously, the source is available to fork ... but I just wanted you to be aware of my situation.

I am actually retired, and have the freedom to move technology stacks (just for fun :-) I have become a strong proponent of Svelte, and am working on several utilities in that domain.

Ah, I hadn't really checked on the last commit date. I can understand that you moved on. Svelte is also great! When I retire (eventually, haha... don't wanna make you feel like an old guy :P) I also want to continue learning and doing new stuff... I have a feeling that when you stop doing that, you rapidly age.

Might I ask if you know of similar libraries like this project?

[KevinAst]

I am not aware of any other offering quite like feature-u. I may have missed the competition, but I think the library is rather unique.

In that regard: Something to consider is a design that removes the react binding (making it more generic). This offering could either offer "a more simplistic" API and/or promote a "plugin architecture" that would apply it's binding to the framework of your choosing.

This may just give the needed "acceptance boost" for the product ... not really sure. At this point, there are so many offerings out there, it's hard to get noticed (i.e. a lot of noise)!

FYI: One key feature that would would be be nice to have in feature-u is the ability to Rebase Active Features at run-time (discussed in this thread).

Keep me posted if you decide to use feature-u.

[KevinAst]

Michel,

In thinking back on one of the issues you raised, I don't think I was strong enough in my defense of the defineUse term. It's been a while since I have been in the feature-u "mindset", but I had a dream about this last night (I do my best work in my sleep - HA).

The final feature-u API was the result of several iterations, involving a number of senior level people. I would strongly defend this terminology in a code review.

To fully understand it you have to better understand and embrace the overall feature-u mindset. It is critical to understand the two broad usage patterns of push and pull (as I mentioned earlier, see: fassets recap: Push or Pull).

The built-in fasset directives (define, use, and defineUse) do have a lot of symmetry. Relative to this discussion, here are some key points:

• fassets (feature assets) is a catalog of resources used to facilitate Cross Feature Communication.

• The define directive catalogs resources on the fassets object

• The use directive identifies a set of resources that will be used by a feature. These resources are supplied (i.e. defined) by other features. When used in conjunction with wildcards, multiple features can inject resources to be used "under contract".

• The defineUse directive is very close to define.

  What defineUse does is a superset of define. In both cases they catalog resources on the fassets object.

  However defineUse adds the following additional constraints:

  1. The resource key (fassetsKey) must match an existing usage contract (supplied by another feature through the use directive).

  2. The resource itself must conform to any validation constraints specified in the usage contract.

  Technically you could get by in using the define directive in a usage contract scenario. However if you violate one of the two additional constraints (provided by defineUse), it will be silently ignored (for the first point) or will error unexpectedly (for the second point).

  If you supply the resource using defineUse, any errors will fail fast, in a more reasonable way (i.e. the error will fully explaining the problem).

Regarding your suggestion to use provide, you could make the argument that provide is a better term. However for consistency it would have to replace both define/defineUse (i.e. provide/provideUse). At this point it comes down to personal preference. In the overall scheme of the various usage patterns, I prefer define.

With that said, I suspect your objection was more related to the compound term (i.e. two terms in defineUse).

With this additional information, the video presentation (at time 53:16) may make more sense.

Hopefully that provides some additional insight.

Let me know if that makes sense.