Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backoffice: items and loans search #66

Merged
merged 1 commit into from Nov 21, 2018

Conversation

ntarocco
Copy link
Contributor

@ntarocco ntarocco force-pushed the loans-search branch 7 times, most recently from d31c573 to b397457 Compare November 20, 2018 15:02

export const http = axios.create(apiConfig);

const toIsoString = date => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to avoid custom date parsing, and go on with the de facto momentjs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I have evaluated that already, but it is a NOGO for what we need:

Copy link
Contributor Author

@ntarocco ntarocco Nov 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, in my current develpoment (next PR) I am finding my self manipulating dates again, so it makes sense now to add a lib since there is nothing native that works nicely.
After investigation, it looks like Luxon (Memento child) is a good compromise. Here some "why".
I am using an it looks quite nice. WDYT? (ping @zzacharo @kprzerwa)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Luxon looks quite good to me for what they describe in their docs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

date-fns could be a candidate, I haven't use it though so no strong opinions, here is a comparison with moment.

let message;
switch (status) {
case 401:
message = 'You are not authenticated. Please login first.';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the error response from server come with a message? If so, would it make sense to use what comes out of the box?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the default message is not very user friendly. For 401:
"message": "The server could not verify that you are authorized to access the URL requested. You either supplied the wrong credentials (e.g. a bad password), or your browser doesn't understand how to supply the credentials required.",

Imaging that reading our message librarians should understand what to do.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't come out of the box, it comes with the box ...

export const IS_LOADING = 'IS_LOADING';
export const ITEM_DETAILS = 'ITEM_DETAILS';
export const ITEM_DETAILS_HAS_ERROR = 'ITEM_DETAILS_HAS_ERROR';
export const IS_LOADING = 'item details/IS_LOADING';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefixing the actions with the actual caller component looks clean and intuitive.
About the prefix though I think I would go for ItemDetails as its class or any other pre-agreed combination of camel or snake case, but the space there is killing me.

Copy link
Contributor Author

@ntarocco ntarocco Nov 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I knew it! I actually commented with @zzacharo saying: "I am sure that if I put a space Chris won't be happy!" but I played my chances :)
I can change it if preferred. (@kprzerwa)

Example:
screenshot 2018-11-20 at 17 12 27

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think we should change the space 😉

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@@ -0,0 +1,74 @@
import React from 'react';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be terribly wrong, but these look like tests for the SearchBar input. I am under the impression that react-search-kit comes with one out of the box. The point I am trying to convey here is that it should not part of the ils application to test each library's functionality, if that happens to be the case.

Copy link
Contributor Author

@ntarocco ntarocco Nov 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I am overriding template and behaviour. React-SearchKit will come with tests for default implementations, but if you override and provide your own...


export const http = axios.create(apiConfig);

const toIsoString = date => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Luxon looks quite good to me for what they describe in their docs

};

const getRecord = itemId => {
return http.get(`${itemURL}${itemId}`);
const mapStatus = s => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you think it would make sense to define those human readable states in the backend and get them from there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO, REST API should never change data, because you don't know which client is going to consume it.
It is exactly the responsibility of the client to present data in human readable format, depending on the context (users, timezone, device, etc...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed mappings

export const IS_LOADING = 'IS_LOADING';
export const ITEM_DETAILS = 'ITEM_DETAILS';
export const ITEM_DETAILS_HAS_ERROR = 'ITEM_DETAILS_HAS_ERROR';
export const IS_LOADING = 'item details/IS_LOADING';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think we should change the space 😉

} from './components';
import './ItemsSearch.scss';

const resultsPerPageValues = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think at some point we could have a separate config file for this kind of things, I have a feeling it will appear in more places, and it would be more comfortable for us to keep it in one place

Copy link
Contributor Author

@ntarocco ntarocco Nov 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is going to be replaced by injecting Invenio config, without hardcoding values. It this particular case, there is no invenio config :) So yes, we should put in common somewhere eventually...
but what about if each search page has different value?

We could decide if it is better to centralize everything, and remember then which config is changing what, or to leave specific view config in its view, so it is easier to see what it will affect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, you would like to fix this in your next PR

);
};

_renderEmptyResults = (queryString, resetQuery) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it possible to make it reusable for other searches? Because I can see that some bits are repeated in the LoansSearch

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, but as discussed in the DevOps, it is a deliberate choice, I don't know how this thing will evolve and the look and feel is very undone now...
I have the feeling we will pass through the full UI when making it more sexy, and the we can do this refactorings.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, we will refactor this in the future

@ntarocco ntarocco merged commit aea08de into inveniosoftware:master Nov 21, 2018
@ntarocco ntarocco removed the review label Nov 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Back-office ui: implement mockups for search/list pages
4 participants