Tim Donohue [9:55 AM] @here: Reminder that our DSpace 7 UI meetings begin at the top of the hour (~5mins) in Slack. The first 1/2 hour will be Angular UI updates in #angular-ui. The second 1/2 hour will be REST API updates in #rest-api channel. Tim Donohue [10:01 AM] @here: Welcome, our DSpace 7 UI meeting begins now in this channel. We'll kick things off with updates on the Angular UI work. As I've been traveling a bit the last few weeks, I'll hand this over to @art-lowel :wink: Art Lowel [10:01 AM] hi Matteo Perelli [10:01 AM] Hello! Art Lowel [10:02 AM] @sourcedump added a PR for the ngrx-store-freeze meta-reducer. https://github.com/DSpace/dspace-angular/pull/84 [10:02] ngrx-store-freeze will ensure that the state of the ngrx store isn’t mutated anywhere, by applying Object.freeze on it recursively. [10:02] More info on object.freeze: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze Mozilla Developer Network Object.freeze() The Object.freeze() method freezes an object: that is, prevents new properties from being added to it; prevents existing properties from being removed; and prevents existing properties, or their enumerability, configurability, or writability, from being changed. The method returns the object being frozen. [10:02] That way an exception will be thrown if someone tries to mutate it. [10:03] I’ve reviewed the PR, and it works Tim Donohue [10:03 AM] Nice, sounds like something we'd definitely want Art Lowel [10:03 AM] Looking at it now, I see that @atarix83 reviewed it as well [10:03] So I’ll merge it now :slightly_smiling_face:
Waffle APP [10:03 AM] *artlowel* moved DSpace/dspace-angular#84 from *Needs Review* to *Done* #84 ngrx-store-freeze added and configured Assignees ---------------- sourcedump Column ---------------- Done Open in Waffle Art Lowel [10:04 AM] I did some more refactoring of the rest services. [10:04] I moved requests and responses to their own places in the store, so now the responseCache _only_ handles caching and the state of ongoing request (what their url is, whether we’re still waiting for a response, etc.) is tracked in a separate part of the ngrx store. [10:04] I’m also making some headway with the loading of related resources, but I’m still having some problems ensuring every object is stored only once in the store. [10:05] I’ve been trying to use the same classes to represent an object in the store and in use in the rest of the application, but it’s looking more an more like I’m going to have to let that go, and create a separate version of each model class for use with the serializer and the store. [10:05] The problem is that if e.g. an Item has a property `bundles: Bundle[]`. It can’t be put in the store as is, because each bundle should be stored separately. [10:05] The object cache in the store should only be “one level deep” [10:05] While in the store the Item should only contain a reference to where each bundle is located. [10:05] So the I started giving every DSO a `self` attribute, and storing bundle objects containing only that `self` attribute in the Item’s `bundle` array [10:05] But that’s problematic when you use it in the front end, because you can’t know whether that bundle has been fetched from the rest api already, so instead Item should really have the property `bundles: RemoteData<Bundle>[]` [10:06] But since RemoteData objects consist entirely of observables, they can’t be serialized from a rest api response. [10:06] Hence the conclusion that I’ll likely need a set of model classes to represent the normalized form of the data, where every relation is represented by an ID (or an array of IDs), and a set of classes where relations are RemoteData objects. [10:06] The former will be used in the ngrx store. [10:06] The latter will be used everywhere else, and generated from the normalized versions in the store, using RxJS operators. Tim Donohue [10:07 AM] While that does seem like a bit more work, it seems like it also has the benefit of providing a mapping of REST API to model classes, correct? So, it may be less liable to break if the REST API changes slightly Art Lowel [10:07 AM] precisely Tim Donohue [10:08 AM] So, it seems like a good direction to me then...even though it is a tad more effort (but hopefully not significant work) [10:09] Is the plan to move this along into a PR in the nearish future then (I'm assuming this is just on one of your personal branches thus far) Art Lowel [10:09 AM] yes, and yes I hope to have a PR before the next meeting [10:09] Lotte has been out sick for most of the week, so no further progress to report on the simple Item view page
Tim Donohue [10:10 AM] oh, that's a shame :slightly_smiling_face: Was going to ask about that. So, that's the first UI "view" being worked on, correct? Art Lowel [10:10 AM] indeed Matteo Perelli [10:11 AM] I just start to check for the refactoring so I don't have much to say Tim Donohue [10:11 AM] It seems like we are nearing the point here where it'll be easier to claim UI "view" tickets and move them forward more rapidly. I see we have a ticket for Collection homepage as well (unclaimed) (edited) Art Lowel [10:11 AM] Yeah, that ticket shouldn’t be too difficult [10:11] If you’ve already gone through the tutorials on angular.io you should know everything you need to know to get started on that collection homepage. [10:12] And I realize we’re running low on tasks in the “Ready” column [10:12] after I have a PR for the rest relations I’ll work on getting some more task descriptions out there Tim Donohue [10:12 AM] Do we have a ticket for a Community homepage as well yet? [10:13] (And yes, the Ready column could use more tickets: https://waffle.io/DSpace/dspace-angular) Art Lowel [10:13 AM] We agreed to remove the concept of communities from dspace 7 Andrea Bollini [10:13 AM] this is related to the discussion in https://github.com/DSpace/DSpace/pull/1686 Art Lowel [10:13 AM] was just about to say that :slightly_smiling_face: [10:14] so in that ticket andrea asks wether the abstraction should happen in the rest api or in the ui Andrea Bollini [10:15 AM] right now merge communities and collections is an idea for the rest api with "low" priority Tim Donohue [10:15 AM] I'm not sure I recall this being a finalized decision (maybe my mind is playing tricks on me though). I agree conceptually that this is a "good direction", but I don't know that it's *required* for DSpace 7 Andrea Bollini [10:15 AM] yes, we have decided to wait after dspace 7 for the real merge (at the database / low api level) [10:16] but we also have decided to "sell" communities and collections as merged in dspace 7 from the end-user perspective Art Lowel [10:16 AM] That’s what I remember as well Andrea Bollini [10:17 AM] what happen if the rest api merges these concepts late? is it much work for the angular team to deal with? Tim Donohue [10:18 AM] Honestly, here I'd ask how much work we are creating for ourselves. Our timelines are already "tight" (to get something ready / visible by OR2017). So, if this merging complicates either layer, I'd move it towards low priority Art Lowel [10:18 AM] ofcourse it both adds and removes work :slightly_smiling_face: [10:19] if we have to make separate community routes, components etc… Andrea Bollini [10:19 AM] can the store / rest separation help here? Art Lowel [10:19 AM] but I think, if the rest api doesn’t unify them, we’ll end up with a situation where the UI will have to do 2 calls [10:20] because for a certain id, you won’t know what type of object to expect [10:20] so you have to GET both `/communities/:id` and `/collections/:id` Tim Donohue [10:21 AM] yes, agreed...two REST calls would be an issue Andrea Bollini [10:21 AM] add a READ only endpoint that just make an attempt on the communities and fallback on collection is easy [10:21] the complexity is to define a single return object, and manage WRITE Tim Donohue [10:23 AM] I guess I'm wondering myself whether it's *easier* to leave Communities as-is (yes, I realize this is more work for Angular team, but the routes/components would be very similar to Collections). Is this too drastic of a change in the midst of building a new UI? [10:23] (i.e. we don't have to fix/redo *everything* in DSpace 7, as much as we'd like to) Art Lowel [10:24 AM] if you don’t think it’s feasible at all for dspace 7 @bollini, I agree (to leave communities as they are in dspace 6) (edited) [10:24] otherwise the read only fallback will work until OR2017 Andrea Bollini [10:25 AM] I'm not able to say now for sure that it is feasible... we will know that only after have written some WRITE endpoints Tim Donohue [10:26 AM] So, do we want to table this (i.e. delay final decision) for now then and wait on feedback on WRITE endpoints? Andrea Bollini [10:27 AM] this could mean to arrive very close to OR Tim Donohue [10:27 AM] I admit though, I do worry that there's a lot in the DSpace infrastructure that includes a separation of Communities/Collections (not just the DB layer, but also Solr indexes, statistics, etc). So, I personally have concerns that the REST API will be able to "fake" this merge sufficiently. Andrea Bollini [10:27 AM] I will prefer to decide today if we want a read-only single endpoint and the UI to work against that assuming the risk to have two separate endpoint for write [10:28] or we leave it out for dspace 7 and also the ui will have communities and collections Art Lowel [10:29 AM] As write will have the same problem (if I have a collection object in the UI, I don’t know if I have to POST it to `/communities` or`/collections`) I don’t think a read only solution will hold up until dspace 8 (edited) [10:29] so we’re better off leaving it out then (edited) Tim Donohue [10:30 AM] By "leaving it out" do you mean we'll do both Communities & Collections in DSpace 7?
Art Lowel [10:30 AM] indeed Tim Donohue [10:30 AM] Ok, I agree. Let's leave Communities & Collections in DSpace 7. The merger will come in DSpace 8 [10:31] And with that, I realize we are entering into our 2nd 1/2 hour. So, let's move this over to #rest-api to talk REST updates
Waffle APP [10:33 AM] *Art Lowel* moved DSpace/dspace-angular#70 from *Needs Review* to *Done* #70 Add ngrx-store-freeze Assignees ---------------- sourcedump Column ---------------- Done Open in Waffle Tim Donohue [10:35 AM] As a final note to @art-lowel... per the discussion above, we probably need a few more tickets in the "Ready" column around Communities. Just a reminder, while I'm thinking about it :wink: Art Lowel [10:36 AM] Yeah, I already wrote that down :slightly_smiling_face: |