Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Migration to NX and modularization: No updates; further work will occur in the next three weeks
  • Restore dynamic component decorators: Art gave update on progress of work
    • Q: Where is the map generated? A: in a folder plus one type of DRS files with one file for each decorator
  • Giuseppe assigned to decorators PR, Tim will take a look at this as well
    • Giuseppe will review Alex's PR and provide feedback
    • He will let Tim know if he wants to give an update in an upcoming dev meeting
  • Want to try to get these two merged relatively quickly, need to think about which one to merge first
    • First phase is split into libraries
    • What's the 2nd, 3rd, 4th phase?
    • Goal: Get app folder as lean / empty as possible
    • May make sense to merge the decorators PR first, as it's smaller.  But, Giuseppe will take a look at it to see if it can easily be worked into the NX PR. 
  • Discussing how the NX PR is structured
    • Art notes we may want to consider using the default "libs" directory that NX uses.  Currently, the PR renames this folder to "modules".  Recommends we name "modules" back to "libs" 
    • The current PR is just the first phase.  This is where we is split parts of DSpace into libraries (in "modules" folder).  Currently just two libraries "core" and "shared/utils".  Everything else is still in the "src/app" directory.
    • Future Goal is to get the "src/app" folder as lean/empty as possible.  It should be possible for institutions to use the "src/app" folder for only the code they want to override .  This would let the "src/app" directory work similar to the Maven overlays that were used in DSpace 6 (and below) – "src/app" would let you overlay/override any defaults in the "modules" folder.
    • The main question is how to get to that goal.  This PR is just the first phase.
      • 2nd phase could be to move everything out of the "src/app" folder immediately into a single massive module.  Then 3rd phase would be to break that massive module apart into many different small modules
      • Or, 2nd phase could be to move things out of "src/app" folder little-by-little, into separate modules.  The goal would still be to get everything out of "src/app", but we'd just do it module by module.
  • For anyone interested to check out how NX works, create a new NX app and play around with it
  • There is a wiki page that discusses the NX proposal (as to why to even look at NX)

...

  • Question for Angular experts: can we explain more about the transferState changes configuration in PR 3953
    • State refers to NGRX state – before this PR, after server-side rendering, we would transfer state from server to client (through piece of JSON) and it would have to be done all over again; this PR fixes thatto avoid having the client need to make the same requests already made by the server.
    • Q: Is there a situation where we want to set transferState to false? A: In DSpace-CRIS set 4Science sets it to false in their production instances.
      • It might be useful to document better when to set this to false (and give a reason why)
    • Currently this configurate seems to exist just because there are scenarios where you might want to set transferState to false...but most may want to keep it as true.
  • If anyone interested in discussing test and configconfiguration, there is an an issue open to clean all of this up 

...