<div dir="ltr"><div>Jane,</div><div><br></div><div>As a nondeveloper with development intersections, I'm going to add in my two cents FWIW.</div><div><br></div><div>First off, thank you for bringing this up. It's very intriguing and, honestly, exciting to think about. 
There has been talk about what exactly calls for a switch to 4.0. With 
the switch to 3.0, there was a fundamental shift from a downloadable 
application to a web-based application. 

Perhaps, this fundamental shift could serve as a watershed moment in the evolution of the Evergreen ILS.</div><div><br></div><div>Next, I'd like to speak to the cons that you've listed. As a tragically optimistic person (mostly), I instantly want to reframe the "cons" as "considerations" or "opportunities for growth." So, sorry about that to anyone who immediately wants to resist my tragic optimism.</div><ul><li>I'm never going to presume on anyone to learn something new. With that said, it seems like there has been a lot of "learning something new" in this community. As you say, "
Standalone components are the default in Angular 19, so this could help us get more prepared for that situation."</li><li>In terms of inconsistency, I wonder if something like a "style guide" might help to provide guidance for consistency.</li><li>When listing out dependencies for large, complex projects, it might be repetitive, but that's when boilerplate becomes useful - have the repetition in the listing, rather than in repetitive code.</li><li>In terms of bundled components and when it might be appropriate, the aforementioned "style guide" might also include some guidance for this decision making.</li></ul><div>Thanks for indulging me. Please chuck any nonsense thoughts I've shared into the wastebasket of irrelevance. <br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><b>Ruth Frasur Davis, Coordinator</b></div><div><b><i>Evergreen Community Development Initiative</i></b></div><div><a href="https://evergreencdi.org" target="_blank">https://evergreencdi.org</a></div><div>(650) 265-1193</div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Feb 27, 2025 at 9:10 AM Jane Sandberg via Eg-newdevs <<a href="mailto:eg-newdevs@list.evergreen-ils.org">eg-newdevs@list.evergreen-ils.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Evergreen developers,<br><br>I'd like to propose that for any new Angular components we create, we use the <a href="https://v17.angular.io/guide/standalone-components" target="_blank">standalone component approach</a>.  In this approach, you explicitly list the components and angular modules your component depends on.  This contrasts with the current approach: organizing angular modules such that each component is within an angular module that supplies the needed dependencies.  You can see a few standalone component examples in <a href="https://github.com/evergreen-library-system/Evergreen/tree/main/Open-ILS/src/eg2/src/app/staff/serials" target="_blank">Open-ILS/src/eg2/src/app/staff/serials</a>.<br><br>Pros:<br>* I consider the current angular module approach harmful -- you can see the harm I caused with it in <a href="https://bugs.launchpad.net/evergreen/+bug/2044051" target="_blank">LP2044051</a>.  There's not a reliable safety net that will catch you if you don't meticulously trace all uses of each component and confirm that they are within angular modules that provide the correct dependencies (either directly, or through the modules that they depend on, or their dependency's dependencies, and so on).  You might get a compile-time error, but you might not and -- in blissful ignorance -- break interfaces completely unrelated to the one that you were working on.<br>* Standalone components require less boilerplate code.<br>* Standalone components are the default in Angular 19, so this could help us get more prepared for that situation.<br>* Personally, I have found the explicit list of a component's dependencies useful, especially when writing component unit tests.<br><br>Cons:<br>* Yet another thing to learn (although tbh, I never totally understood angular modules anyway hahaha)<br>* There will be more inconsistency in the different component approaches within our codebase.<br>* Listing out dependencies could get repetitive for large, complex components.<br>* There may be some legitimate uses for components that are bundled together in a module (perhaps components that can only ever be used together?)<br><br>FYI: for anybody else who uses the `ng generate component` command, you can add the `--standalone` flag to create it as a standalone component.<br><br>Certainly, if you've already written some new components using angular modules, I don't want to block you!  But my proposal is that after a certain date TBD, if you create a new component, please make it standalone.<br><br>What do you think?  Very happy to receive questions, counterpoints, etc.!<br><br>Thanks!<br><br>  -Jane</div>
</div>
_______________________________________________<br>
Eg-newdevs mailing list<br>
<a href="mailto:Eg-newdevs@list.evergreen-ils.org" target="_blank">Eg-newdevs@list.evergreen-ils.org</a><br>
<a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs</a><br>
</blockquote></div>