-
Notifications
You must be signed in to change notification settings - Fork 267
Conversation
…lochain-rust into get-links-count
I propose a follow up story in which GetLinks uses the NetworkQuery for the querying of the GetLinks. Could have been done in here but seems out of scope |
Still missing get_by_tag functions but that should be coming soon |
…lochain-rust into get-links-count
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good but I really think we should include a refactoring that merges all these new actions, reducers and futures into just one set of those all queries..
core/src/action.rs
Outdated
@@ -160,8 +160,11 @@ pub enum Action { | |||
/// Last string is the stringified process unique id of this `hdk::get_links` call. | |||
GetLinks(GetLinksKey), | |||
GetLinksTimeout(GetLinksKey), | |||
GetLinksCount((GetLinksKey, Option<CrudStatus>)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed merging Get* / RespondGet* to Query / RespondQuery. That would make this PR already smaller as we would need all that cruft including a new future etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this and just used GetLinks with an enum because one thing I was worried about was the disconnect between what happens on the from the request point of view and the sever point of view. The reason why GetLinksCount was implemented explicitly because following it down the workflow is easy in terms of "new developers" and someone who isn't just new to the system. But I just used an enum as a parameter instead because doesn't over complicate what is happening there.
RespondGet merges and RespondQuery I think is something that should come into play as a later PR imo because some of this stuff can really propagate through a lot of changes making the scope much bigger as it goes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all looks great, especially the tests which cover the different cases. But, as per Nico's suggestion, and my rule that when we repeat things (i.e. copy over boilerplate) for the third time then it's time to generalize. So my requested change is to refactor at least the GetLink* and RespondGetLink* actions and futures into just one Query/RespondQuery with an enum as a the payload that holds either the actual Links result or the count.
So much of the code is the same, that it really seems like a refactor is in order here, and also worth it, because I'm guessing that we may want to be able to add some other enum into list.
@@ -851,6 +851,137 @@ scenario('get_links_crud', async (s, t, { alice, bob }) => { | |||
t.equal("deleted",bob_posts_all.Ok.links[1].status); | |||
|
|||
|
|||
}) | |||
|
|||
scenario('get_links_crud_count', async (s, t, { alice, bob }) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also need to add this test into app_spec_proc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought app_spec_proc copies over this from test.js?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks way better! I still think we should go all the way only talk about queries in our network actions/reducers as mentioned in my inline comments. Also representing GetLinksCount
as its own query seems much cleaner to me.
But the main thing here: the new app-spec test is not passing.
#[derive(Debug, Serialize, Deserialize, PartialEq, DefaultJson, Clone)] | ||
pub enum NetworkQuery { | ||
GetEntry, | ||
GetLinks(String, String), | ||
GetLinks(String, String, Option<CrudStatus>, GetLinksNetworkQuery), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I regard link counts as a different query, instead of a parameter to GetLinks
. I think it would be much cleaner to represent it here in that way too: instead of introducing those enums above, why don't we have a GetLinksCount(String, String)
specialization here?
|
||
//make sure it is equal to 1 | ||
t.equal(1,alice_posts_deleted.Ok.count); | ||
t.equal(1,bob_posts_deleted.Ok.count); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RespondGetLinks((QueryEntryData, Vec<(Address, CrudStatus)>, String, String)), | ||
HandleGetLinksResult((Vec<(Address, CrudStatus)>, GetLinksKey)), | ||
RespondGetLinks((QueryEntryData, GetLinksNetworkResult, String, String)), | ||
HandleGetLinksResult((GetLinksNetworkResult, GetLinksKey)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would love to see these actions and the corresponding action creators and reducers in the network module to not know about links at all and just operate on the generic level of queries.
Checked in with @zippy via chat who is on the go rigth now.
…lochain-rust into get-links-count
…lochain-rust into get-links-count
PR summary
Allow the zome developer to be able to get the link count
testing/benchmarking notes
( if any manual testing or benchmarking was/should be done, add notes and/or screenshots here )
followups
( any new tickets/concerns that were discovered or created during this work but aren't in scope for review here )
changelog
Please check one of the following, relating to the CHANGELOG-UNRELEASED.md
- summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)