Alex-Bakic

WorksHub Issue 30: Setting up the keydown event for drop-down select components

This issue covers the remastering of the drop-down component , and includes things like the introduction of keydown, click and close events.

As we need to reference the DOM element itself, we need to use some underlying javascript APIs to get this done, and so we will need to interop at some point. To add event listeners to items we need to make sure that those items are already rendered and part of the web page, so doing something like this wouldn't work:

(into [:ul {:id "dropdown--options" :tabindex "0"}]
          (map (fn [{:keys [id label]}]
                 (let [unique-id (str "dropdown--item--" id)]

[:li {:id unique-id

Alex-Bakic

WorksHub Issue 20: Allow users to update edit their Career history.

This issue goes over the creating of a feature that allows a user to delete and manage their CVs through a more expressive setup, of using buttons and messages , rather than inconspicous behaviour within the "upload cv" button.

A user is allowed one CV file, and one external CV , and there should be a little message below [:h2 "Career History"] that mentions this to the user:

;; so something like this
[:section.profile-section.cv
 [:div.cv__view

[:h2 "Career History"]

Alex-Bakic

Alex-Bakic

Cancelling the application process

The aim is to allow the candidate to click on an "x" button within a job card on the applied page, and have that process terminated.

The checks that must be ran before showing this close icon is the following:

- make sure the user is logged-in
- make sure on-close is nil, as if it is not nil, it means that we are on a page that should
  be reloading likes. Would need to then tweak applied page to reload only for closing jobs, and not liking.

We will need to reload, though this is done within the event chain itself, saving us from tweaking the ::toggle-like event.

Alex-Bakic

I'm feeling lucky button : development and walkthrough

The aim of this button is to allow users who are logged in , and have a somewhat completed profile , to simply click on the button and begin applying for random jobs. For just how random depends on how much we want the success of the button to work, which will impact it's randomness. For example, we could pull out of recommended and then give the candidate a chance of actually landing a job. But the recommended section isn't very large as it is pulled in on a page-by-page basis, and unless we call the entirety of the recommended jobs (which would be overkill) it wouldn't be very random, although 20 or so options is good. We wouldn't really want to make a graphql request though for a completely random job, say that uses Scala when the candidate uses Clojure, and if by some miracle he got the job he probably wouldn't want to take it. For now though , in this prototype , the button is in the recommended section.

So when the user hits the button, befo

Alex-Bakic

Extension of issue 6 , to do with reloading and the hidden bug highlighted in the /job common page.

The reloading of recommended jobs and the dashboard is currently solved, though leaving the applied page out has left bugs, and ones similiar to those in the last issue which is where we find a job in liked without the "liked" selected indication. This is partly because we don't re-render, but there is another issue underlying this one. Let's first take a look at the page function within wh.logged-in.personalised-jobs.views:

(defn page [type-of-jobs]
  (into
    [:div.main
     [:div.spread-or-stack
      [:h1 (str (-> type-of-jobs name str/capitalize)) " Jobs"]

(when (= type-of-jobs :recommended)

Alex-Bakic

# Extension of issue 6 , to do with reloading and the hidden bug highlighted in the /job common page.

The reloading of recommended jobs and the dashboard is currently solved, though leaving the applied page out has left bugs, and ones similiar to those in the last issue which is where we find a job in liked without the "liked" selected indication. This is partly because we don't re-render, but there is another issue underlying this one. Let's first take a look at the `page` function within `wh.logged-in.personalised-jobs.views`:

    (defn page [type-of-jobs]
      (into
        [:div.main
         [:div.spread-or-stack
          [:h1 (str (-> type-of-jobs name str/capitalize)) " Jobs"]
          (when (= type-of-jobs :recommended)

Alex-Bakic

Mini walkthrough of the reloading issue...

For the moment , with the like button on job cards, when they are clicked they do not trigger reloads of the recommended or dashboard pages, contrary to the blacklist button. What blacklist does is take the job out of the sub-db path [:wh.logged-in.personalised-jobs.db/sub-db ▶{..., :wh.logged-in.personalised-jobs.db/jobs [{} , ... , {}]}] and puts it in the blacklisted ▶{:wh.user.db/sub-db {:wh.user.db/blacklist #{"remote-junior-maker-of-everything-dd48b"}}} section. ::toggle-job-like does the same, but the difference being blacklist will recall either the dashboard or the recommended page to show that it has been removed:

(reg-event-fx
  ::blacklist-job
  db/default-interceptors
  (fn [{db :db} [{:keys [id] :as job} action]]
      {:graphql         {:query      blacklist-job-mutation

:variables {:id id}

Alex-Bakic

(ns wh.components.job
  (:require
   #?(:cljs [wh.components.ellipsis.views :refer [ellipsis]])
    [reagent.core :as r] ;; added purely for our like-job-post component, delete this if you don't want to the use below
    [wh.common.job :as jobc]
    [wh.components.cards :refer [match-circle]]
    [wh.components.common :refer [wrap-img link img]]
    [wh.components.icons :refer [icon]]
    [wh.interop :as interop]
    [wh.re-frame.events :refer [dispatch]]