The recipe get tags method was failing when a nil recipe is provided.
Not sure when that would happen, but without fixing it, we can just
return nil when a blank recipe is returned.
Still having the stupid ass nil dereferences, I think I might need to
migrate to using success returns instead of pointers. Because they're
fucked. And even more so now.
This includes backend updates as well as frontend changes! The backend
also includes a new repository to get a list of jobs via their IDs,
which does respect order!
The list displays for users that are logged in and a small message when
the user is not logged in. The last piece is the recipe of the week
segment, which can be as simple as a DB cron-job. But that will require
stored procedures. Need to learn those next.
Though I want to deploy the application soon, so I need to begin working
on that.
This basically marks the favorites page completed. Updating the recipe
repository to allow the search function to accept a userId and favorites
flag. This flag will toggle a "favorites only" search. Which can be used
to replicate the same functionality from the search page in the
favorites page. This later can serve as a baseline for updating to also
work for activity search.
I am starting to think an ORM is a good idea...I heard Gorm is good, but
for now, there is a bit too much tech debt.
This means we need to pass the user id into the various methods that
call it. But, since it is a pointer, we can use nil if we don't have a
user to check with (this is noted in the service).
The profile list will now properly display the users recipes! The
favorites list does not exist yet, since there is no backend support for
favoriting/saving recipes. So the list displays the same content as the
user recipe list. Same goes for the activity list, not yet implemented.
This is part of the step towards finishing the creation wizard, all that
is left is the image. However, that is a bigger problem since it
requires a file store and file server. But for now, tags are implemented
and working!
This is a HUGE upgrade and can mark the searching nearly complete! Other
than the scrolling and some other smaller UI things. The search appears
to be working.
The search is nearly complete for the initial implementation. Just need
to figure out what to do with the text search provided, make any
required UI changes, and eventual implement pagination via a "load more"
button.
Missing some context storage and better passing of data to allow
between the home page to the search page. Need a way to store the search
results in state so they can be retrieved when the page is reloaded,
etc.
Furthermore, not sure how we are going to handle the searching. Maybe a
full-text search index? For now, it has been ignored, but the filters
seem to be working properly.
The route will now display real, live data from the DB! Errors are not
handled very well, just returned as JSON for now. Need to implement an
error page for states when errors occur.
This commit also includes lots of documentation for the various
service/repository methods. I am trying to not let docs fall through the
cracks, but I am not perfect lol.
Most everything is implemented, included a state handler and a pretty
simple (but workable) system for managing state in HTML. Nice and simple
for now.
There is still much work to be done, but the rest is simple backend
creation and error handling. And then input validation...a nightmare.