-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How does data-ref get its value? #89
Comments
Ah, @TakenPilot this is the same issue I had when I wanted to do stuff to the layout instance. |
For whenever this is brought up again, these are the reasons why there will never be a
|
Could there be an easier solution by targeting the .html route, since that is the only place where we need the I am not sure about "No one cares about data-ref except for the editor." Data-ref is how we are indicating that an element is a component, which can be used as a querySelector. |
By whom? The editor? By client-side JavaScript? I don't think overloading the meaning of data-ref is healthy either. It's data that is a reference. If someone is assuming that a data-ref means something is a component, they're the one making an assumption. : ) Someone else could use class names. And someone else could use data-component. That last one would be the most accurate, don't you think? I really don't think telling another project like byline-core and multiplex-template about your data-ref that's only used in yet another project is anything close to maintainable or recommended. Please help keep our projects in their own bins. |
Example: Someone needs to implement a feature with hardcoded strings in their project. They use gulp. Instead of adding the feature in their own project, they decide to modify gulp because it was easier, putting their hardcoding strings for their own project right into gulp's code. And now they're expecting gulp to merge their PR. You're trying to put "data-ref", your hardcoded string, into projects that have never seen that before in their life. Note: multiplex-templates also has no idea what a |
What I am suggesting is to expose the ref, which byline already knows, to the render engine. Locally, I think I have this working by adding one line of code: adding |
Right, but why? You just want to do that to make a particular other project react in the way you want, when you could do the exact same thing in this project instead. So why would byline-core want to do that? What will the docs say to justify it? "We decided it would be cool to be special in this one case, because reasons, so deal with it." :D I mean, you certainly can't say that you're doing it because some project that depends on this one needs this exception. That's admitting that this editor is the only main consumer of the byline-core api. That's also admitting that having that project separate really doesn't make any sense, because we've coupled it directly with the editor. If byline can only exist with this particular editor, then we should merge the projects. If that's the decision, I'm okay with that. We can merge the editor code into byline-core or vice versa, and that would actually make it easier to manage the addition and removal of the editor from templates. This might be a really good idea! Merging the editor and byline-core together would mean that I am 100% okay creating tight coupling between the code bases. If you're going to add an exception to another project because it's easier than adding it to your current project, you're going down a weird path, right? Especially since you're only doing it because you're trying to handle a use-case that doesn't make any sense to begin with -- having a data-ref on a non-root element when their entire reason for existence is to help with the replacement of html components. |
Let's phrase this another way: I believe that this project and byline-core should be merged together as much as I believe that the factory and ambrose should be merged together (which, again, I'm not totally opposed to). What you're suggesting is something like this is added to the article endpoint on ambrose because it would be so very convenient for the factory: if (data.articles.length === 1) {
data.date = articles[0].date;
} I mean, yeah, it could be that all the templates in the factory would benefit from a line like that, because we use the article endpoint so much. The guys running the ambrose project would probably scream at you though. "Why?" they would ask, "It's inconsistent!" and you might reply, "But it's so easy! Look, here's a PR." |
In effect the ref is already getting passed to multiplex-templates as follows: In lib/composer.js:
Another approach I am thinking about is using a filter to add the ref through a nunjucks filter; there might be a way to make it work with the current version of byline. @yoshokatana, is it possible to extend the embed filter in an instance of byline? |
Ah, I see, that's... 😅 My words aren't so convincing, so... I guess submit a PR? Though I would consider the ROI of your use-case vs how many days you're spending on this. When you get a chance, maybe run the actual problem that you're trying to solve (replacing components in the html) past @yoshokatana . Seems like its a problem that's already been solved since the first demo months ago, and this is a black hole of logic. I'm going to close this issue, because you and @yoshokatana really need to talk, and this is a black hole of logic for a feature where you're discussing editing another project to serve this one. We should either move the discussion there as a feature request, in which case we can actually answer the request, or we should create a new issue here that discusses what actually can be done in this particular project (the editor). |
Note that when you request y directly, the data-ref is empty.
Perhaps
_ref
should be considered the ref of itself within the context of a nunjucks template. If this is confusing with the usage of_ref
elsewhere, we could use_self
within the nunjucks template. This would mean data-ref would have the same value in both.../instances/x.html
and.../instances/y.html
.For example, the template could be
An advantage to this approach is that we can rely on the html to always have the data-ref defined when replacing a single component within a page, as we are currently doing in byline-editor.
A disadvantage is that there would need to be logic in byline that assumes that all users of byline would always want to have _ref or _self available in the component's html template. Currently we are only using the _ref in the templates so that byline-editor knows where components are on the page.
The text was updated successfully, but these errors were encountered: