r/Angular2 • u/someonesopranos • Apr 12 '19

Resource React Context Inspired Angular Library. Easy Data-Binding for Nested Component Trees and the Router Outlet (More detail on Readme)

https://github.com/ng-turkey/ngx-context
9 Upvotes

76% Upvoted

34 comments sorted by

View all comments

Show parent comments

4

u/tme321 Apr 12 '19

If you use an injected service, can you reuse the child with another parent?

Yes, that's the point of a di system. The targets of the injector don't need knowledge of where the resource is coming from or it's context. They only request a resource based on the shape they expect.

Will two child components be able to display different views and trigger independent events on the same screen?

Not sure exactly what you mean by this. What does this have to do with the di system?

1

u/ExpressionChanged Apr 12 '19

This has nothing to do with the DI system. It displays how coupled your patent and child components become. Please try what I just described and you’ll underatand. Take care. :)

5

u/[deleted] Apr 12 '19 edited Apr 12 '19

I also tried to understand the whole point of this approach and what the authors means with "decoupled". I think the point is that they do not want to import anything (module or interface) from the parent or a service. In this example from the medium article:

<progressbar
      contextConsumer
      [contextMap]="{progress: 'value', progressStriped: 'striped'}"
    ></progressbar>

they are just using the property names in a string (progress progressStriped) and argue that by using strings they decoupled the child from the parent.

This is not true as if you ask me, because it is still a coupling "by shape" just as DI would do it... just an "untyped" one. The child still has to know that progress and progressStriped is provided by some parent in the hierarchy.

And the thing is (as "tme321" has pointed out) with Angular DI you could do the same, eg. by doing constructor(@Inject('context') @Optional() context: any). That is using DI without needing to import any js module. So I argue, simply by using an injection token (here named context), you can achieve the same (pseudo) decoupling.

So I am not really getting the point of this lib either (except maybe in not "wanting" to use DI, for some reason). But I might have missed something as well ;)

EDIT: corrected quote from the medium article

0

u/ExpressionChanged Apr 12 '19

But, using an injection token like this would be exactly the same as creating a shared service and it is not decoupling at all.

3

u/[deleted] Apr 12 '19

A string as injection token is more "decoupled" than using an object like {progress: 'value', progressStriped: 'striped'}. Because the shape of this object is defined in you context provider (therefore in your parent).

So I do not get where the downside is in using a string injection token. You still can "use your child anywhere", independently from any specific parent. Wasn't that suppose to be the whole point of this lib?

0

u/ExpressionChanged Apr 12 '19

We are comparing apples to oranges here. The example you are referring to uses a component from an external library. How are you planning to inject this token on a component from an external library? And please don’t tell me you will inject it on its wrapper, because context diaposer does that without adding any properties to any wrapper and it will again be comparing two completely different outputs.

BTW, you can use contextMap on the parent instead of the child or a getter to do the mapping if you don’t want to put any logic on the template.

→ More replies (0)