Even though I visit discuss daily the latest batch of responses flew under my radar. Now there is so much to comment on.
I’m not familiar enough with the context of modern frontend builders to weight on the config vs code decision, but I think this proposal by kyle is a gem:
We should provide developers with a good ammount of flexibility so they can decide if the want a lot of options in a fragile API or a robust API that might not have all the options available. I have met many in both sides of that line.
I think this is a wonderful thing. Less 2U specific code, while we maximize the capabilities for other developers to also extend the UI and make great experiences! If there where no other reasons, for me this would alone be quite the goal, but we also have the option to gather real world data on usage of this mechanism. We at edunext intend to use it extensively and report back our findings.
To the broader point of filters/events vs slots. The way I understand it, slots are filters. Maybe pre-configured filters, but filters anyway. They let you alter things in the existing code at pre-determined places. The syntax for configuring them is indeed a bit different, but considering we are also switching language and the server for the browser it was to be expected. Now, something that we learned in the hooks framework was that having a unique ID and documenting the filters carefully was the main way to actually making them usable and stable for developers to build upon. We went to great lengths to make sure that filters and events would not break all the time. I suggest we do something similar here.
I think Regis strikes an important nerve here. I understand we are desperate for extension at the frontend, but leaving a trail of ADRs, which have had ample time to comment on them, makes the whole system fireproof. As a maintainer of the events and filters packages I count on those long discussions to make sure that nobody on a tight schedule deletes/modifies/alters an API without following due processes. Moving ahead with v0 and improve the API post Redwood for me means doing exactly this. Let’s take the rushed prototype and make it fireproof by means of having all the ADRs, OEPs, long discussions like this and every other necessary discussion until there is consensus for the accepted solution.
I’m not going to dispute that going with the current state of FPF into Redwood is experimental at best - though I hope I made the reasons for it clear - but I’d like to address the following concern:
I would love suggestions on how to improve this. I get the feeling that no matter how wide we throw the net, however long we wait, only a few fish people ever find their way into reviewing the PRs that we publicize. In my experience, in addition to the forums and on Slack, publicizing these during meetings seems to get the best results. In any case, I’ve done all of the above several times over many months in this particular case - and still some people were “surprised.”
See, I think more people have the same concern as you - I certainly do myself - but I suspect they just don’t have the bandwidth to participate. And that is a problem I don’t have a ready solution for.
For the record, I brought this exact concern up today during the Contributor’s Meetup in the context of this issue. There were some good ideas about how to address at least a part of it. (I’m still in the meeting, so can’t post a recording yet, haha.) One of them was to channel important happenings that people should keep an eye out for into a curated, condensed format. An actual plan is pending results of the collaboration survey.
It really does sound like I’m the only one complaining, so you probably shouldn’t worry too much There is a very strong possibility that the process has worked just fine in this particular case. Only future will tell. I propose we go on with our lives and revisit this thread in a few months, with 100% hindsight.
Poor OEP-56 was (is?) concerned with making sure we shared architectural decisions/concerns with the right people, but we never really made good on that vision, to my knowledge. (Which is definitely partly my fault for not being able to see it through).
It represented a process by which we communicate via push, to some extent, rather than just pull. Busy people don’t often have time to pull/go hunt down what’s happening.
There is a very strong possibility that the process has worked just fine in this particular case. Only future will tell. I propose we go on with our lives and revisit this thread in a few months, with 100% hindsight.