These are chat archives for assetgraph/assetgraph

16th
May 2017
Andreas Lind
@papandreou
May 16 07:00
@Munter We could use this new eslint selector syntax to help decouple relation classes from JavaScript assets: http://eslint.org/docs/developer-guide/selectors
Peter Müller
@Munter
May 16 07:08
I'm not sure I follow
Andreas Lind
@papandreou
May 16 07:09
Each relation class could provide a selector, and findOutgoingRelationsInParseTree could do a single traversal of the AST, matching up all the found nodes
Instead of the huge if...else...else...else
Peter Müller
@Munter
May 16 07:13
oooh. That indeed would be nice. Same thing could apply to html
Andreas Lind
@papandreou
May 16 07:13
yeah
Peter Müller
@Munter
May 16 07:13
One step closer to being able to hook into this step in the lifecycle?
Andreas Lind
@papandreou
May 16 07:14
Not sure exactly what that would entail
Peter Müller
@Munter
May 16 07:15
By registering my own custom relation I could have it picked up by the assets parseTree traversal instead of having to implement my own override
This could make us extensible with relations we're not interested in having in core
Andreas Lind
@papandreou
May 16 07:15
What sort of override would you have to implement otherwise, and what would it accomplish?
wrapping findOutgoingRelationsInParseTree?
Then yes, it would accomplish exactly that .)
:)
Peter Müller
@Munter
May 16 07:16
Pretty much. But I'd have to do my own tree traversal again, because there is no hook per tree node
Andreas Lind
@papandreou
May 16 07:17
When you say "hook into this step of the lifecycle" I pictured something else
Yeah
So it would accomplish that, but we need a strategy per asset type
Peter Müller
@Munter
May 16 07:19
Maybe we could come up with a transition state where we can do both until we have similar selector capabilities for the remaining types
Andreas Lind
@papandreou
May 16 07:20
Yeah, we can keep calling the relations finder method the same
Peter Müller
@Munter
May 16 07:20
Per node, check the relations selector matches. If no match, do this if/else check, which we currently do
Andreas Lind
@papandreou
May 16 07:20
Oh
What would that accomplish? Do you think anyone is presently overriding findOutgoingRelationsInParseTree?
Peter Müller
@Munter
May 16 07:24
No. But I'd like to enable them to hook in, so externals could implement support for their own crazy js loader, or whatever else people can come up with
I'm just thinking of all the blockers I know people have hit from the questions I've been getting
Andreas Lind
@papandreou
May 16 07:25
Ah, so "this if/else check" is something that a plugin would provide?
Peter Müller
@Munter
May 16 07:25
A loader hook is a big one. Not being able to extend the relation types another
It would just be what we currently have. Unless you also planned to completely replace get parseTree with this change
Andreas Lind
@papandreou
May 16 07:27
I don't think that would be wise
That should probably remain separate from getting to the relations
Peter Müller
@Munter
May 16 07:35
I'm up for an evening where we define some architecture that can replace the current one
Andreas Lind
@papandreou
May 16 07:36
Me too, but let's wait until we have some time to spare so we can actually get it done
I have a couple of other things in progress
Peter Müller
@Munter
May 16 08:28
Me too