[FEATURE]: Vault page (search published brews) (alt title Archive)

[5e-Cleric]

This is just me trying to create the most wanted function, find published brews by title.

This PR creates a new Page, called the vault page, it also creates a new API endpoint to get files based of title, with multiple additional filters.

As per last update, has 2 separate request that are run simultaneously in first load of query, then only one of them is run with every reload. This avoids timeouts.

Added files and their functions:

• vaultPage.jsx
• vaultPage.less
• vault.api.js

Modified files:

• homebrew.jsx: added Route for the page
• brewItem.jsx: modified author display to show 'no authors';
• app.js:

There is no nav link to the page just yet. Go to https://homebrewery-pr-3263.herokuapp.com/vault

Changes

For a next PR

• [x] Turn to functional component
• [ ] Use $search or $facet methods
• [x] Use splitPane component
• [ ] Use listPage component
  • [ ] add Splitpane inside listpage
  • [ ] move query to outer page and just send the results
  • [ ] move filter and sort options to backend at least for Vault, due to pagination.

ToDo in this PR

• [x] Change Page size to page count (name)
• [x] Page count from input to select
• [x] Disable button programatically
• [x] Fix CSS for background not filling the page correctly
• [x] unable selection

[5e-Cleric]

toDo list:

• [x] move from admin.api to its own
• [x] use ~listpage.jsx and~ brewitem.jsx
• [ ] add filtering functions
  • [x] renderer
  • [x] cloned or not (-CLONE should do it)
  • [x] excluding words?
  • [ ] views?
  • [x] authors?
  • [ ] theme
• [x] implement agnostic UI
• [x] response brew count
• [x] page size query option

[5e-Cleric]

Adding here talk from gitter chat:

brews: null is getting pushed to console twice on every update, but the search only occurs on Enter/button click Correction: it hits the console twice on a page refresh I assume this is due to the this.lookup() in componentDidMount, so it runs a search as soon as the page loads

Ah .. here's the way to search for a whole word: (^|[^a-z])DM($|[^a-z]).

A ssearch for [PF2e] takes a long time and returns a huge result of which very few actually contain the string "[PF2e]". This is because it's actually doing a regex search for any title that contains, in any order, any of the characters p,f,2,e. Oops.

So .. proposal: instead of defaulting to regex (with a failback of exact string match if invalid regex), do a exact string match by default, with the exception being if the search string is indicated to be a regex by wrapping with /.

Thus: Search [PF2e] will find titles containing that exact string; /[PF2e]/ will do a regex search.

This is the same way in-brew search/replace also supports regex. No need for a UI widget (e.g. checkbox) to indicate if regex applicable.

[ericscheid]

Very exciting, lets keep this moving..

1. searching for a term that does has zero matches gives the false explanation of

   I'm sorry, your request didn't work

   Your search is not enough specific, too many brews meet this criteria for us to forward them.

2. The error message itself is black text on the dark blue backgound. (#2C3E50)

[5e-Cleric]

Yes, i am aware, however, i am right now trying to figure out pagination ( i know how it works, i just keep hitting error after error(my normal working process)).

[ericscheid]

Clicking the pagination links is funky..

1. 👍 the desired page of results is displayed
2. 👍 the pagination indicator for the newly displayed is highlighted
3. 👎 the window.location.href improperly updates ..
   • if clicking the pagination page number links, window.location is not updated at all
   • if navigating by the << or >> buttons, window.location has the previously displayed page number, not the newly navigated to page number

(Unrelated: 👎 hitting (e.g.) https://homebrewery-pr-3263.herokuapp.com/archive?title=dagger&page=5 does not load the 5th page of results — it does not load any page of results. This makes testing this aspect impossible at the moment.)

[5e-Cleric]

3. 👎 the window.location.href improperly updates ..

   • if clicking the pagination page number links, window.location is not updated at all
   • if navigating by the << or >> buttons, window.location has the previously displayed page number, not the newly navigated to page number

That is an interesting matter, not sure why that happens, i might not update the page state properly before calling updateUrl

(Unrelated: 👎 hitting (e.g.) https://homebrewery-pr-3263.herokuapp.com/archive?title=dagger&page=5 does not load the 5th page of results — it does not load any page of results. This makes testing this aspect impossible at the moment.)

Hate to say it, works fine on my end, reached even the 6th page.

[G-Ambatte]

Preserving @calculuschild's comment from Gitter about Mongo searching, as apparently search capabilities differ, depending hosting:

---

So you should be able to do something like this:

{ $search: {
        "index": "default", // optional, defaults to "default"
        "text": {
            "query": "dragon",
            "path": "title",
            "fuzzy": {
                "maxEdits": 1,
                "prefixLength": 0,
                "maxExpansions": 50
            }
        }
    }
}

maxEdits: Maximum number of single-character differences allowed to be considered a match. Value can be 1 or 2. The default value is 2. prefixLength: Number of characters at the beginning of each term in the result that must exactly match. The default value is 0. maxExpansions: The maximum number of variations to generate and search for. This limit applies on a per-token basis. The default value is 50.

[5e-Cleric]

Searching works again, after lots of tweaks, the index read is "title_text", will try creating a separate PR to try the $search stage method.

[Gazook89]

Not sure if you are looking for this kind of input yet or not, but I'm going to shoot my shot here. Pretty much all of these bulleted items i think are "minor nitpicks" that can probably be addressed fairly easily one-by-one (though there is some overlap).

• [x] A. Can you revise your first comment on this PR to clearly explain what is added, how to access it, and what might yet need work either in this PR or a future PR? It was immediately clear to me how to access this Archive page-- I thought i'd find it in the User menu, or on the Share page, or something. I suppose that will come later, but for now it needs to be mentioned up top that this page is only accessible via the address bar.
• [x] B. I think you should get rid of Your results, my lordship. I only saw this when testing on local, I don't see it on the deployment, so maybe not a problem? I'd just be sure it's gone.
• [x] C. Pretty much all of the text that isn't in an input should use CSS to make it non-selectable/not use the "text cursor" on hover.
• [x] D. The "whenever you want, just start typing" area might be improved by just showing a default result ("most viewed", "most recent", etc). At minimum, I wouldn't use "whenever you want, just start typing..." as text in this area. This gives the impression that I should either type in that area of the window, or can start typing without focus on any input. If not doing a default search result as suggested, this text could just say "showing no results" or similar.
• [ ] E. I'm not even sure that the Archive page needs to differ from the User Brew List page that much-- the brew list page already has a filter/sort bar which is relevant to Archive results as well. No other page has a big banner at the top declaring the page name. And the two side-by-side portions, if kept, could likely benefit from splitPane as well.
• [x] F. I don't think a number input is the best option for "number of results", and the current attributes are not great (mystifying was the first word that came to mind). Instead, <select> menu with options like just 15 & 30, or 15, 30, 50.

<label>Results per page<input
    id="size"
    type="number"
    min="6"
    step="2"
    max="30"
    name="pageSize"
    value="12"
/></label>

• [ ] G. If more renderer versions come out, the URL parameters will have to be updated since it is handled like this: &v3=true&legacy=true. Is it possible to just send something like &renderer=legacy,v3 so that additional future renderers can just be added to the list?
• [x] H. I prefer count over size for the param setting the number of results returned.
• [x] I. Going further on the URL, is it better to arrange the parameters like this: /archive?title=monster&renderer=legacy,v3&count=12&page=1? To me, the page parameter is the most dynamic of the set-- having it at the end makes it easier to change if using the address bar (or scraping results).
• [x] J. Do these parameters have defaults? It seems like all of them besides title should have defaults so that a simple query like http://localhost:8000/archive?title=monster would work. I think sensible defaults with the current params could be:
  • renderer: legacy,v3
  • count: 15
  • page: 1
• [x] K. Maybe disable the Search button (and style it as such) if it's not going to function-- for example, pressing Search when no search text has been entered does nothing.
• [ ] L. Perhaps we can load the mongo 'stop word' list and check the search string against it before submitting. If a user tries to search just "and" it's going to return no results....so we can just prevent the submission preemptively. Probably there is some other validation we can do, like making sure the search string is at least 3 characters or something.
• [x] M. This might be resolved by another suggestion above (using splitPane or matching the overall form of the user brew list), but currently the blue background in the resultsContainer doesn't extend to the bottom of the screen, and neither does the associated scrollbar. Several CSS methods to fix this.

Finally, one bigger question that is beyond a nitpick: Is there a benefit to having this separate archive page in addition to a user brew list? Or could there be a single page for the two--- navigating to the "users own brews" would just set an author parameter on the search that matches the username. And via the UI you could remove or add authors to your search query. If this Archive page is available to non-users (or users not logged in), which is another question, then going to the Archive would obviously not default to the current user's brews.

Anyway, if you want help with any of the points above I can submit PR's on your PR. Otherwise this is all just up for discussion.

PS. I think the end result of this PR is huge, so good work 🚀

[5e-Cleric]

Point by point

A. Can you revise your first comment on this PR to clearly explain what is added, how to access it, and what might yet need work either in this PR or a future PR? It was immediately clear to me how to access this Archive page-- I thought i'd find it in the User menu, or on the Share page, or something. I suppose that will come later, but for now it needs to be mentioned up top that this page is only accessible via the address bar.

Sure, no problem, Calc asked that the nav change came in another PR

B. I think you should get rid of Your results, my lordship. I only saw this when testing on local, I don't see it on the deployment, so maybe not a problem? I'd just be sure it's gone.

I changed it for Your searched returned these results, but i should probably change that, I wanted to make it visually different from edit and homepage, but i guess i could go with the theme.

C. Pretty much all of the text that isn't in an input should use CSS to make it non-selectable/not use the "text cursor" on hover.

I don't believe there is a single page where we have done that:

But i can make that no problem

D. The "whenever you want, just start typing" area might be improved by just showing a default result ("most viewed", "most recent", etc). At minimum, I wouldn't use "whenever you want, just start typing..." as text in this area. This gives the impression that I should either type in that area of the window, or can start typing without focus on any input. If not doing a default search result as suggested, this text could just say "showing no results" or similar.

I don't personally like showing no results if no search is done, that response is reserved for an empty search. But i agree it should be changed.

E. I'm not even sure that the Archive page needs to differ from the User Brew List page that much-- the brew list page already has a filter/sort bar which is relevant to Archive results as well. No other page has a big banner at the top declaring the page name. And the two side-by-side portions, if kept, could likely benefit from splitPane as well.

I am not using listpage.jsx for some reason i don't remember, i think i needed to refactor some logic in listpage to work correctly, will go over it again.

I will ask this on the gitter chat to make sure everyone agrees, but using splitPane makes sense, i just don't want to get caught another month just modifying the component to fit. Actually, i'd rather we do this in another later PR.

F. I don't think a number input is the best option for "number of results", and the current attributes are not great (mystifying was the first word that came to mind). Instead, <select> menu with options like just 15 & 30, or 15, 30, 50.

Eh.. not sure there is much difference but i can make that, would be more similar to how it was made in other websites.

G. If more renderer versions come out, the URL parameters will have to be updated since it is handled like this: &v3=true&legacy=true. Is it possible to just send something like &renderer=legacy,v3 so that additional future renderers can just be added to the list?

H. I prefer count over size for the param setting the number of results returned.

I. Going further on the URL, is it better to arrange the parameters like this: /archive?title=monster&renderer=legacy,v3&count=12&page=1? To me, the page parameter is the most dynamic of the set-- having it at the end makes it easier to change if using the address bar (or scraping results).

Good suggestions, will take a look at that, they don't look like problems to me, but something more left to choice and taste... and i'm not sure if i can make the renderer one, don't know much about queries

J. Do these parameters have defaults? It seems like all of them besides title should have defaults so that a simple query like http://localhost:8000/archive?title=monster would work. I think sensible defaults with the current params could be:

• renderer: legacy,v3
• count: 15
• page: 1

both renderers have a default of true, count has a default of 10, page has a default of 1:

title: this.props.query.title || '',
legacy: this.props.query.legacy !== 'false',
v3: this.props.query.v3 !== 'false',
pageSize: this.props.query.size || 10,
page: parseInt(this.props.query.page) || 1,

K. Maybe disable the Search button (and style it as such) if it's not going to function-- for example, pressing Search when no search text has been entered does nothing.

good idea!

L. Perhaps we can load the mongo 'stop word' list and check the search string against it before submitting. If a user tries to search just "and" it's going to return no results....so we can just prevent the submission preemptively. Probably there is some other validation we can do, like making sure the search string is at least 3 characters or something.

I can whip up a simple regex pattern for the input, but i suck at doing your super complex validation that you have done in other files, could use a hand with that. We could also do it in another PR

M. This might be resolved by another suggestion above (using splitPane or matching the overall form of the user brew list), but currently the blue background in the resultsContainer doesn't extend to the bottom of the screen, and neither does the associated scrollbar. Several CSS methods to fix this.

thought i had fixed that, damn CSS

Finally, one bigger question that is beyond a nitpick: Is there a benefit to having this separate archive page in addition to a user brew list? Or could there be a single page for the two--- navigating to the "users own brews" would just set an author parameter on the search that matches the username. And via the UI you could remove or add authors to your search query. If this Archive page is available to non-users (or users not logged in), which is another question, then going to the Archive would obviously not default to the current user's brews.

I'd rather that not be the case, that would be a huge component to load just for the userPage, and the different routes... idk If done, in another PR

Anyway, if you want help with any of the points above I can submit PR's on your PR. Otherwise this is all just up for discussion.

i'd appreciate that, could you take a look at M and possibly G? should be fairly easy without knowing the code.

PS. I think the end result of this PR is huge, so good work 🚀

[ericscheid]

G. If more renderer versions come out, the URL parameters will have to be updated since it is handled like this: &v3=true&legacy=true. Is it possible to just send something like &renderer=legacy,v3 so that additional future renderers can just be added to the list?

A more common code pattern is to simply have multiple checkboxes with the same name attribute, such that when submitted you get &renderer=V3&renderer=legacy.

Is there a benefit to having this separate archive page in addition to a user brew list? Or could there be a single page for the two--- navigating to the "users own brews" would just set an author parameter on the search that matches the username. And via the UI you could remove or add authors to your search query. If this Archive page is available to non-users (or users not logged in), which is another question, then going to the Archive would obviously not default to the current user's brews.

A hiccup to this plan is that we are planning on supporting folders and so forth on the /userpage

[Gazook89]

A more common code pattern is to simply have multiple checkboxes with the same name attribute, such that when submitted you get &renderer=V3&renderer=legacy.

Yeah I saw that too when searching around a bit. Is that burdensome when we have &renderer=legacy&renderer=v3&renderer=v4&renderer=v5?

I don't know how searching by tags exactly works, but lets say it's just passing the tags to params in a similar fashion....should we have &tag=foo1&tag=foo2&tag=foo3&tag=foo4 etc?

I'm okay with the suggestion, just thinking out loud in case it's worth considering.

[ericscheid]

A more common code pattern is to simply have multiple checkboxes with the same name attribute, such that when submitted you get &renderer=V3&renderer=legacy. Yeah I saw that too when searching around a bit. Is that burdensome when we have &renderer=legacy&renderer=v3&renderer=v4&renderer=v5?

I don't know how node/react handles plurality, but other platforms will usuaily ingest such as an array for handling. (PHP does that automatically if of the form &arg[]=1&arg=2&arg[]=3)

I don't know how searching by tags exactly works, but lets say it's just passing the tags to params in a similar fashion....should we have &tag=foo1&tag=foo2&tag=foo3&tag=foo4 etc?

Yes. Whichever way we send the query parameters they'll need to be ingested into an array, and then when doing the search of the tags array we can't use $in and we'll want to do as case insensitive, so we'll need to use regex and the array element test of $elemMatch.

[5e-Cleric]

This is ready for a merge. Everything not finished will be done in a separate, later PR.

[5e-Cleric]

At this point, i'll keep adding things until i can merge, but the PR is ready.

[Gazook89]

I think before this gets merged, it should include some way to navigate to the vault page in the navbar. I'm not sure where it should go at this point-- in my opinion, we don't have a great logical place for it except yet another button in the top nav bar. That should suffice for now. I do not think it should go in the Account menu-- it shouldn't be necessary to be logged in to search for brews.

For an icon?: <i class="fa-solid fa-dungeon"></i>

either that or fa-search.

[Gazook89]

Are you interested in adding more search fields? I am thinking additional fields like "Author" and "Tags", so you could search by specific fields, or a combination of fields.

For example, do a search right now for theme:

Let's say I don't like that sor_robertson guy and don't want to see his brews. Right now, in the search box, I might try to modify my search like theme -"sor_robertson", expecting that I could use the negation to remove his brews.

That doesn't work.

Or, let's say I like that Gazook89 guy, and I just want to see his brews...obviously, i could just use the address bar to look at his user page, but let's pretend this is my first day on the internet. Doing a search for Gazook89 only returns one result...a cloned brew by some other user with "Gazook89" in the title.

I might also want to search for brews by specific tags, like "meta:theme", or "system:pf2". Currently, those don't do anything (though I know there are some brews that have those tags).

I think as far as layout goes, you would have the main search more visually prominent, and then the additional fields in a <detail> accordion, or just below the main search box.

[Gazook89]

Trying to break my comments here into separate chunks-- 'nav', 'features',-- and now 'styling'. Also, I thought I could run this PR locally but doesn't seem to be working for me. I knew it obviously wouldn't have access to the production database but I thought I'd be able to view the page at least? Let me know if i'm just doing it wrong.

For styling: What do you think about just matching the styling of the Metadata/Properties editor? Gray background, the inline labels, square corners on inputs, button colors and fonts, etc. I was hoping to run locally and quickly test how easy it would be to just link the same stylesheet, and how much effort it would be to change the html structure so it would work.

I think that placeholder text in inputs could be removed, and the "example" (in this case, "v3 reference document") be placed just below the input in small text. But honestly, I don't think any example text is really needed.

v3/legacy buttons don't need to have "yes"/"no" options with a handwriting font-- they could simply be checkboxes.

There should a min-width set on the overall form now that we are using split pane (granted, the Properties editor doesn't have one, yet).

I might suggest changing "Brew Lookup" to "Vault", and then a subheader like "Search for brews" or "brew search" or similar. For some reason, I think "Lookup" is a weird word/phrase that might not translate well. Regardless, i think "Vault" should be more prominent than just being in the navbar.

[5e-Cleric]

I think before this gets merged, it should include some way to navigate to the vault page in the navbar. I'm not sure where it should go at this point-- in my opinion, we don't have a great logical place for it except yet another button in the top nav bar. That should suffice for now. I do not think it should go in the Account menu-- it shouldn't be necessary to be logged in to search for brews.

For an icon?: <i class="fa-solid fa-dungeon"></i>

either that or fa-search.

I do prefer the door icon, but we should talk to the rest. I will add this navigation on the PR.

At some point, specially for mobile, we should consider an icon-only navigation, or a big dropdown. On the topic of nav items, i think changelog and faq should have more nav items.

[5e-Cleric]

Are you interested in adding more search fields? I am thinking additional fields like "Author" and "Tags", so you could search by specific fields, or a combination of fields.

For example, do a search right now for theme:

Let's say I don't like that _sor_robertson_ guy and don't want to see his brews. Right now, in the search box, I might try to modify my search like `theme -"sor_robertson"`, expecting that I could use the negation to remove his brews.

That doesn't work.

Or, let's say I like that Gazook89 guy, and I just want to see his brews...obviously, i could just use the address bar to look at his user page, but let's pretend this is my first day on the internet. Doing a search for Gazook89 only returns one result...a cloned brew by some other user with "Gazook89" in the title.

I might also want to search for brews by specific tags, like "meta:theme", or "system:pf2". Currently, those don't do anything (though I know there are some brews that have those tags).

I think as far as layout goes, you would have the main search more visually prominent, and then the additional fields in a <detail> accordion, or just below the main search box.

I haven't tried multiple field search, i am not sure if it would be easier or harder on the server, but i can try. We have plenty of space to accomodate more fields without the need of an accordion or advanced search option.

First search option should be tags, so i will focus on that.

[Gazook89]

I made a branch on your branch but haven't pushed it to GH yet. But here is the current status:

Small variations from the Properties editor include the stacked label/input rather than side-by-side. I thought this might condense better at low widths. Personally I think the Properties editor could/should do this, too, but that's another day.

I also understand that a more prominent title on the vault might be desired, so here is a variation:

Another thing I'm wondering is if the background should be a lighter gray, for this and for the Properties editor, to increase contrast with the text.

Edit: I neglected to add styling for <code> bits, so those don't currently stand out from the rest of the text at all...but was just an oversight and can be done.

[5e-Cleric]

Small variations from the Properties editor include the stacked label/input rather than side-by-side. I thought this might condense better at low widths. Personally I think the Properties editor could/should do this, too, but that's another day.

I also understand that a more prominent title on the vault might be desired, so here is a variation:

Another thing I'm wondering is if the background should be a lighter gray, for this and for the Properties editor, to increase contrast with the text.

Edit: I neglected to add styling for <code> bits, so those don't currently stand out from the rest of the text at all...but was just an oversight and can be done.

Don't have strong feelings about this... I don't really enjoy the overly long inputs, even if they work better at smaller widths.. and would prefer to stay away from the default appearance of the checkboxes, as i am sure you will have noticed. I like the title, specially if we include it with the icon as suggested in gitter. And those are <small> not code. Overall, thank you for paying attention to the project :)

[Gazook89]

And those are not code.

I believe it's small with the syntax marked by code, right? Anyway, in my branch i switched out small anyway, for just a styled div:

<div id='title-tip' class='tip'>
						<i className='fas fa-info'></i> you can use <code>-</code> to negate words, and <code>"word"</code> to specify an exact string.
					</div>

And the input itself uses aria-describedby to point to that element:

<div className='field'>
					<label for='title-search'>Title</label>
					<input
						id='title-search'
						className='value'
						ref={titleRef}
						type='text'
						name='title'
						defaultValue={title}
						onKeyUp={validateForm}
						pattern='.{3,}'
						title='At least 3 characters'
						onKeyDown={(e)=>{
							if(e.key === 'Enter') {
								if(!searchButtonRef.current.disabled) {
									loadPage(1, true, true);
								}
							}
						}}
						aria-describedby='title-tip'
					/>
					<div id='title-tip' class='tip'>
						<i className='fas fa-info'></i> you can use <code>-</code> to negate words, and <code>"word"</code> to specify an exact string.
					</div>
				</div>

[Gazook89]

don't like normal checkboxes

I have preference for normal checkboxes, but on a whim I put this together, which could be achieved with a normal checkbox altered with just CSS (using background images):

Edit: Or another:

(this one could even be animated, with the bubbles appearing one at a time, set to loop or just run once on click....not saying we should or shouldn't, but we could)

Thoughts?

[5e-Cleric]

I actually prefer the sword one better, far easier to see. We could try to animate that, but we could turn mad trying.

FYI right now the search is disabled (just the button and enter key) if both fields are empty, or if both renderers are unmarked.

[5e-Cleric]

Disabling "Author as owner" check, it is not worth the trouble for those slim changes in the results IMO. Keeping the functionality just in case we need it later.

[5e-Cleric]

Situations to test:

• [ ] With author, without title
• [ ] Without author, with title
• [ ] with both
• [ ] both or only one renderer for each option above
• [ ] all variants with title using exact words, or negated words (I tried making this into a table, but checkboxes don't work inside tables)

[5e-Cleric]

Timeout issues solved by applying a compound index of title and published status.

Left toDo are:

• Cleanup
• Styling (can be done in a separate PR)