-
Notifications
You must be signed in to change notification settings - Fork 13
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
feat: [sveltekit-pod] Issues Search: inline filters (open/closed) #973
Conversation
✅ Deploy Preview for jazzy-gecko-7ceb2c canceled.
|
✅ Deploy Preview for elaborate-baklava-440c0a canceled.
|
✅ Deploy Preview for lucent-kleicha-c0913e canceled.
|
✅ Deploy Preview for superb-nasturtium-3dbf18 canceled.
|
✅ Deploy Preview for remarkable-caramel-0ba9f6 canceled.
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
This pull request is automatically being deployed by Amplify Hosting (learn more). |
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'm not acquainted with svelte, but I have some coments/questions on this PR. Please answer them. :)
svelte-kit-scss/src/lib/components/IssueSearch/IssueSearchControls/IssueSearchControls.svelte
Outdated
Show resolved
Hide resolved
on:select={async ({ detail }) => await handleFilterSelect(detail)} | ||
> | ||
<svelte:fragment slot="option-icon-left" let:option> | ||
{#each [resolveStateFilterIssueState(option)] as state} |
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.
Do I understand this correctly?
- You put one item into an array to iterate over it.
- This array will always have one item which can be undefined or a truthy value
- If it is truthy it renders an icon.
This seems to be something that's a bit overengineered, isn't it possible to only use one if statement here instead of iterating over an array that is created every time? 🤔
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.
svelte doesnt support in-template scoped variables at the moment.
sveltejs/svelte#1521
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.
Huh, that's inconvenient.
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.
Yeah, the framework grows fast still... And they will to solve the problem i think
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.
But I wouldnt like to upgrade the version at the moment. Thoughts?
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.
Well leave it this way then, but this is something that I think is very ugly. :\
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 think the same..
svelte-kit-scss/src/lib/components/shared/buttons/SelectButton.svelte
Outdated
Show resolved
Hide resolved
type TOption = $$Generic; | ||
export let options: TOption[]; | ||
export let labelAccessor = (option: TOption) => String(option); | ||
export let checkedPredicate: (option: TOption) => boolean = () => false; |
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.
correct me if I'm wrong, but this always returns false and does not really take an option. Is that intended?
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.
It makes the checkedPredicate input property as optional (with default value)
It is a common practice for reusable components
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.
So, these are like component properties?
In angular these would be @Input()
decorators?
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.
Yes. Absolutely the same
@@ -33,6 +33,17 @@ export const splitFilterParameters = (query: string): string[] => { | |||
}, [] as string[]); | |||
}; | |||
|
|||
export const ensureRepoParameter = (query: string, repoName: string): string => { | |||
const repoParam = splitFilterParameters(query).find((x) => |
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 have a feeling that this part is rather overengineered here. I don't really understand what needs to be done here. Are there any tests for these? 🤔
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.
It checks if the repo parameter in the query. If not we have to add current one. It is how it works in native github. To check that just try to play with issues search in native github...
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 kind of wanted to see where you ended up with these, but it seems to me like we really need a few things:
A type of object that represents the search filters, I think this would include the PREDEFINED_SEARCH_QUERY_PARAMETER_GROUPS
you have defined, and also the parametrized options like repo:
, is:issue
, milestone:
, sort:
and whatever else.
Then we would have a function that can convert from a string to an object of that type, and from an object of that type to a string.
If you had those 2 things separate, and tested, then I think you could clean up a lot of this code, because it would most involve creating URLs from the state objects, and parsing the current route into one of those objects.
What do you think?
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.
The object model and builder will be too complex this way
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.
But I would do this with pleasure if we will have time
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.
It seems overly complex now, and spread out.
I was hoping it would make it simpler and "all in one place"
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.
Should I make it more reusable?
<DropdownFilterTextButton text="Sort" /> | ||
</DropdownMenuSelect> | ||
<div class="primary"> | ||
<SelectButton |
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 seems to be unnecessarily complex for what it is.
We've effectively got 2 "tabs", or links, open and closed, and one of them is currently active.
What you have here seems very very configurable and extendible maybe, but unnecessarily so.
I think you maybe need to take a step back here, and just have the 2 links, Open and Closed, be always visible here with their Icons hardcoded, and use the state filters to provide the 2 links with the label
, the href
and whether or not they have an active
class applied.
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.
- Motivation: The purpose of the showcase is to show how to solve the differnet kind of problems with svelte and sveltekit.
On typical real life projects there are Frontend and Backend team.
This aproach gives an ability to separate backend and frontend part of work. - I created a separate components for all the things. Every components has as less responsibilities as possible in order to follow SOLID and DRY principles
- I think the best sveltekit application is like a constructor:
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.
Yeah, but as a showcase, for someone to look at and understand, "oh this is what a SvelteKit app would look like", this doesn't fulfil the need.
This is hard for me to understand, and might give someone the impression that SvelteKit "requires" or demands code like this for very simple things, which it does not.
I would prefer anyone unfamiliar with Svelte or SvelteKit be able to look at this code and immediately recognize what part of the app it is from and how it works.
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.
Could you please help me to understand what is my bad? It looks very simple to me. I tried to use as much svelte features instead of hardcoding.
Lets clarify... What the snippet is most hard to understand?
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.
Should I make it less reusable?
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.
Okay. Now I got your point,
But have some confuses:
- this approach will rerun the backend code each time you hover on the link (To reproduce, just add console.log to page load function)
- It will require styles duplication.
- if the filters will be returned in different order - it will cause wrong look
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.
Are you ok with that? Should I remove SelectButton component?
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 approach will rerun the backend code each time you hover on the link (To reproduce, just add console.log to page load function)
this will cause us to often get github throttling error
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 approach will rerun the backend code each time you hover on the link (To reproduce, just add console.log to page load function)
This is a "feature" of SvelteKits prefetching we've opted into on the body, which we can (and maybe should) turn off by removing this data-sveltekit-prefetch
atrttibute:
<body data-sveltekit-prefetch>
You should also be able to opt out for certain links and sections by adding a data-sveltekit-preload-data="off"
attribute to the link or a containing element but that doesn't seem to work (though it should, so a sveltekit bug?)
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.
Corrected
@@ -33,6 +33,17 @@ export const splitFilterParameters = (query: string): string[] => { | |||
}, [] as string[]); | |||
}; | |||
|
|||
export const ensureRepoParameter = (query: string, repoName: string): string => { | |||
const repoParam = splitFilterParameters(query).find((x) => |
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 kind of wanted to see where you ended up with these, but it seems to me like we really need a few things:
A type of object that represents the search filters, I think this would include the PREDEFINED_SEARCH_QUERY_PARAMETER_GROUPS
you have defined, and also the parametrized options like repo:
, is:issue
, milestone:
, sort:
and whatever else.
Then we would have a function that can convert from a string to an object of that type, and from an object of that type to a string.
If you had those 2 things separate, and tested, then I think you could clean up a lot of this code, because it would most involve creating URLs from the state objects, and parsing the current route into one of those objects.
What do you think?
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 think this is mergeable, we can look to further refactoring in the future
* Dinamic filters: Milestone filter. Dropdown adjustments * fix label * Milestone filter adjustments * Code review fixes
* Dinamic filters: Milestone filter. Dropdown adjustments * fix label * Milestone filter adjustments * resolve redirect for issues search pages * adjust linked components * adjust linked components * Code review fixes * Code review * Code review
…hub.com/thisdot/starter.dev-github-showcases into 901-sveltekit-pod-issues-inline-filters
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.
Partially resolves #901
Includes: