-
Notifications
You must be signed in to change notification settings - Fork 0
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
build modal of task details #18
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…div for the left side of the modal (which is the first 'column' of the checkbox for marking the task as complete), and right side being all the other values and inputs for existing task's details. rename all ids to avoid nameclashing with the new-task-modal
…em on the <main> part of the page, and the expanded task details in the modal
…in to the top of the checkbox to manually align
… right side of the modal for task details to have more meaning (self-documenting)
…odal for task details
…in03/to-dos into build-modal-of-each-tasks-details
…se functions can be reused across add new task modal as well as edit existing task modal
…tched on + svg icon for urgency going from outline to filled) to both add task modal and edit existing task modals
…including 'Inbox' or not
… of the task object in <main> section (task preview) this is because of issues with attaching event handlers if it's just sitting in the html
…dal is being generated
avoids issues with selecting the right element for event handling.
…re the project name was not showing on the header of the project page
… task purpose is to be able to uniquely select that task, even if it has the same name
…viewing details of tasks, down to the generation of the specific task's modal for its details. at the moment, this hasn't really been utilised within the functions, but it is the best way to uniquely identify the task
this is so that we can properly retrieve the task from localStorage
yes, this is just calling the helper from localstorage, but i don't want any dom elements to be using the helpers - they should ONLY be interfacing with App
…modal for the particular task's details, rather than just the id this means we don't need to reconstruct the task from its id again at the displayTaskDetailsInModal level
…thods just yet) by _name_. this is because when a user is creating a task, they don't get to see the ID, so it can't really interface with the equivalent helper using id. names are also unique now, in that they will always have a suffix
* store id as a property of tasks * add optional parameter for task factory that aligns with project factory in that there is a setter for ID, but only can be used when reconstructing from JSON * skip past certain attributes when generating a task div (in main section of page), including id * do not show new task's project if it is added there for future * remove old flow for console version of app * add diagram * stores projects in localStorage in the 'projects' key of localStorage. remove id from the details of project as this is already the key * write helper function that retrieves project by name * add retriever to get projects as objects, or aretrieve projects as an array * enforce uniqueness of project names by readding projectExists check from localStorage helpers, imported into project factory * get all projects in modal for adding task and viewing (expanding) task details * ensure correct helper function is called in app controller. remove comments * catch error on intitial load of app (when localStorage is empty) and return an empty array * rename task getter tasks, in the current design of the data structure, will be an array of task ids * check first if the project being stored already is a project in storage * fix -- adding new project does not replace all previous projects now * add new task's unique id to the array called 'tasks' under projects * inspect task details * add localstorage helper function that retrieve all tasks as objects * update diagram to add prefixes to ids to better distinguish tasks and projects from each other * update diagram to reflect design - we want projects to have a P prefix in its id, and tasks to have T prefix to better identify them. Inbox is going to just be 'inbox' for its id * check if task is existing because tasks is an array, we don't want to just be completely replacing the tasks array when storing - we will lose all of the other tasks. instead, we need to get the entire array, remove the task if it exists, then push it back * align the way that tasks and projects are stored * update recreation of project from json by adding that the recontsructed project should replace all of its tasks with what is stored in json * simplify storing of tasks * enable adding of task to inbox and other projects and properly storing into localStorage * display project names in nav. add attributes for id and name id is for future-proofing for when we allow for duplicate project names * throw error if duplicate project names are found * create getter for id of project so that it can be called in updateHeader for when user clicks on a new project page * update header of each projects page. we now try and leverage id of project instead of tasks because it is more unique * rename methods and variables in project trelating to tasks clearer that projects just store the more lightweight ids * write method for projects to get the tasks as objects because tasks are stored in an array of task Ids for project, this then retrieves the entire object (task) from the ids * fix -- error when an empty project is clicked from nav and attempted to be displayed. if there are no tasks mapped to the project, just return out of the methods * fix -- align naming of attribute of projects relating to tasks being task id and not 'tasks' anymore * refresh the project page you are on after you add a task, whether to that page or not * ensure ordering of projects in dropdown of modals align with the order in the nav to avoid confusion * fix -- was calling the old localstorage helper in check (also in localstorage helper) whether a project name already exists * have localstorage helper retrieve project by id id is the most unique identifier * at the app level, get the project by id * display page based on projectId parameter, not project name anymore * initially display inbox based on the 'inbox' project id * update data attributes of project link divs in nav. pass project id to nav link click handler instead of name simpler data attributes allow easier calling of those attributes' values when required * pass id of inbox in when clicking the branding in navbar * update hardcoded data attributes of inbox link * rename helper * simplify arrow function * move pseudocode * when checking whether project name exists, we remove parentheses with numbers inside, then trim the white spaces on each end, to confirm if the project name already exists * write setter for name of project * create project using their name, but now there is a suffix to help distinguish them * ensure that name is being reconstructed for projects. fixes issue where the project name was not showing on the header of the project page * add task id as data-attribute to the article element representing the task purpose is to be able to uniquely select that task, even if it has the same name * rename method for opening modal for given task. pass task id through viewing details of tasks, down to the generation of the specific task's modal for its details. at the moment, this hasn't really been utilised within the functions, but it is the best way to uniquely identify the task * instantiate app controller this is so that we can properly retrieve the task from localStorage * add getTask method in App yes, this is just calling the helper from localstorage, but i don't want any dom elements to be using the helpers - they should ONLY be interfacing with App * pass task object through to the function creating and displaying the modal for the particular task's details, rather than just the id this means we don't need to reconstruct the task from its id again at the displayTaskDetailsInModal level * restore helper function to retrieve a project object ((without its methods just yet) by _name_. this is because when a user is creating a task, they don't get to see the ID, so it can't really interface with the equivalent helper using id. names are also unique now, in that they will always have a suffix
… you are on is passed, and not the name
…in03/to-dos into build-modal-of-each-tasks-details
…opulate task name value in modal
…rieved from localstorage for a task when expanded nicer to have getters rather than calling .viewDetails().propertyname
project is populated by the current page project's name. i've done this so i don't have to manage having 'projects' as its own attribute for tasks which, at the moment, feels like a lot of overhead
henrylin03
added a commit
that referenced
this pull request
May 24, 2024
…you're on (#40) * update title of html page. comment out all of index.js to switch off all of the alerts/prompts in dev * normalise css * import stylesheets into entrypoint js. remove scroll-behaviour for now * add sidebar and branding. make title clickable * remove spread syntax from webpack.common.js because not using any other css minimisers * remove css minimisers. change order around of rules for webpack config according to asset-management guide of webpack documentation * remove normalisation in style.css as well * build base, html template (#5) * update title of html page. comment out all of index.js to switch off all of the alerts/prompts in dev * normalise css * import stylesheets into entrypoint js. remove scroll-behaviour for now * add sidebar and branding. make title clickable * remove spread syntax from webpack.common.js because not using any other css minimisers * remove css minimisers. change order around of rules for webpack config according to asset-management guide of webpack documentation * remove normalisation in style.css as well * restore normalisation in style.css as well * add links at the top by top we're talking about just the 'inbox' link for now, but we want to future proof for other links in the future, like 'completed' and 'trash' tasks * move javascript files into js folder for clarity * add inbox icon * add relative path of svg image for testing * install and configure copywebpackplugin to recreate an assets file in dist/ when built * add project-links section in sidebar * call sidebar now <nav> semantic html is better seo and is better self-documenting => improved maintainability * add plus svg. create folder to hold navbar icons for clarity * update copy to reflect current wireframe (makes it look more realistic too as actual, likely, potential project names). add icons * make 'projects' in sidebar a heading. add the plus icon next to the link to add new project * remove underlines from anchor links, and remove colour (purple in chrome) of anchor links once visited * import and update fonts * specify the 'tasks' logo text to clarify in selectors and also in html * increase size of logo text * add colours as variables in css * add colours to texts in sidebar * adjust font-size * add classname to nav for clarity * remove margin from all heading elements. add header * update font colours * add main section html elements. add comment for section in style.css * ensure height of body is always 100% of viewport (dynamically too) * create grid thinking here is that, at this highest level, there will only be two columns - left one for the sidebar, and right-one for the header and main section. there will be two rows - top one for the header, and bottom one for the main - sidebar will stretch across both rows * stretch sidebar top to bottom across grid * add padding to sidebar. reduce relative width of sidebar * add padding to header * add padding to main section. update background colour of header and main sections * update colours * make h2 selector more specific - it is only for the sidebar this is in case we use h2 for other headings in the main section or elsewhere in app * make entire sidebar a flex container * centre-align logo * add gap in sidebar (top-level for sidebar) flex container * adjust class names allows consistent styling despite inbox or projects links. add a .projects class as i know i will probably need to select this div with my js * increase padding for sidebar on the x-axis * make container of links a flex-container. apply this also to the 'add a task' in the header * make the container of links a flex-container, and add gap to space them out. add 'black' colour that is actually on theme with our primary colour this feels easier on the eyes now that it is not 'true' black * adjust padding of sidebar * adjust padding of sidebar. colour the text of the special link in sidebar that allows users to add project * slightly reduce font-sizes with roboto, it looks quite big at 100% on my chrome browser * add actual svg of the plus symbol into the html enables it to be coloured by css rather than hardcoded into the svg xml * narrow sidebar * enable css to modify the size of svg * restore original size of svg easier to actually just change the hardcoded values in svg * add divider line. reduce length. adjust colour * add divider and adjust the margin to negative * add div containers to each of the links * add background colour, adjust font-colour and font-weight for inbox this class will be manipulated (added/deleted/toggled) using js * reduce padding of the sidebar we want the padding to be actually inside of the container * adjust padding of the container for the anchor * restyle divider to ensure there was no weird shadow on it * use the actual svg as the icons of the sidebar links so that they can be coloured when selected * update svg icon for projects * better align projects heading in sidebar * make boldness of font when selected to be more subtle * implement flex-grow on sidebar links to ensure alignment vertically * make entire header flex container * add comments * use actual inbox svg in the header (.left class). make .left class a flex container. enables colouring and other manipulations of the svg. wrapped it in a figure for semantic html * resize svg icon in the header representing inbox some hacky tweaking required because visually it doesn't look aligned - the icon and the text - even though i've done align-items: center * remove copy-webpack-plugin usage not using any svgs stored in the folders, but directly as html so they can be manipulated by css. can always reinstall in the future if i use it again! * increase padding for header * adjust alignment of projects title in sidebar * build `<main>` section with dummy tasks (#6) * remove to-do comments relating to features required. add to-do comment on tasks needing deletion the to-do comments that have been deleted are already in the pr #5 as a task * add basic, html elements (completely unstyled), hardcoded into index.html, for all the tasks currently in wireframe to style * add background colour (white), padding, and round out corners of tasks * update titles of tasks per wireframe in index.html * add wrapper around the non-name attributes of task makes positioning a bit easier, as the task name is at the top * colour attributes of task grey, and make attributes' font-size smaller this is to better contrast and highlight the task name itself * make the second row of the task a flex-container easier to style, and it is only one axis. if it were two, i might have used grid instead * add wrapper around the right-side of the task. remove other tasks for now that are hardcoded into html this is to make flexbox positioning a bit easier * make each task a flex container so that the checkbox is on the left, and the task's information is the on the right * center tasks. implement a width that doesn't go all the way to the end. change padding of header to align * use flexbox to position tasks in the main section. add gap vertically between them * add question as comment for future * reduce padding in tasks. make the right-side of the tasks a flex container to more easily manipulate gap * make tasks less rounded * add box-shadow to tasks * make each attribute of task (not the name) a list item in an ordered list this is more semantic, and is easier to style, because there's already a dot separating them right now! * make list inline and remove styling for now inline is just for clarity. it doesn't actually do much here considering task-attributes are already a flex-container * increase gap * remove dot point for the first list child * remove display: inline because flexbox is easier to control. update gap of flex box so that the distance between the dot divider and text is the same * add container around checkboxes * style checkbox, including in checked status. make checkbox round * add styling for task's due date if the date is 'today' * fix merge conflicts * reduce size of icons * reduce vertical gap between the title of task and its attributes * wrap attributes with icons with a div container, and then wrapped in a <li> list item this enables the marker to be visible * use ::before element on the list items, and adjust gaps using margin and flexbox gap on the .task-attributes unordered list easier to manipulate than the ::marker selector * reduce gap between attributes * update background colour of completed task * all text and icons on completed tasks are gray * put line through the title of a completd task * update how to select the urgent attribute container to avoid clashing. update box shadow increases visibility, especially for the completed task * add border to left of urgent tasks * remove unused comment * ensure overdue tasks have orange dates * adjust location of checkbox when there is a border to the left for urgent tasks. reduce size of checkbox, and update the checkbox border to align with design (primary colour, blue, border around round checkbox) * update hover colour of the 'add a new task' anchor on the top right of the page * add animation so colour slowly fades in on the 'add a task' on the top-right when hovered over. colour also fades out * add hover effect on checkbox * use pointer cursor on tasks they are meant to be clickable per design in order to expand the task and modify any of its attributes, and deleting it entirely * when user hovers over a task (completed or not), a filter is applied and the background-colour is changed. added transition for smoothness * add comment * rename 'add a task' container accordingly .right was not really intuitive, and might lead to confusion in future * on click, the 'add a task' container reduces in size gives responsiveness to the user which is great * add pointer cursor on all parts of .link anchor (not just the text and svg). round out corners * add hover effect to links in the sidebar * reduce size of sidebar links on click * simplify selectors * simplify selectors for link in sidebar. remove effect when clicking on a sidebar link where the text reduces in size the animation/effect when clicked looks cheap * add a really long project name to test feature * implement text overflow for sidebar links all we really need to see completely is the 'add a project'. everything else can be truncated on smaller screens * truncate description of tasks on smaller screens * rename files. add empty DOMController factory module DOM Controller will be the object that interacts with DOM * link up dom controller to index.js entry point, and test add event listener on the add project button. make add project button (really an anchor) have an id there is only one place to add a project * create modal for adding project * rename dom controller to screen controller. do not use default export this is so that just in case we export .addproject() as well from screenController.js * rename dom controller to screen controller. do not use default export. create app controller factory, and import into screenController. add comments to plan out next steps used non-default export so that, just in case, we export .addproject() as well from screenController.js * app.addProject will handle creating a project using project factory, and storing it into localstorage * reset project name so that if user wants to add another one, there isn't the old project name that was just added there * remove commented out code * remove unused comments * add empty getProjects method for app controller * simplify creation of new project code * if not already existing, create 'inbox' project to hold non-project-tagged tasks * do not call (circular calling) another storage helper in retrieve All. import helpers into appController * write method to get all project names at the moment, we don't need all of the project's objects. however, i know we will need this in the future * add comments for clarity * prevent creation of project with empty string argument * removed comments * select projects in sidebar * add wrapper around current projects' links this excludes the title, and the add-project button at the bottom too, to make it easier to manipulate * create project div element in DOM. get project names as an array from localStorage using helper function * replace all existing projects with those from localStorage not including 'inbox' of course * remove dummy projects from sidebar * fix: runtime error when adding two projects, using enter key. the name of the project is a blank string, and was either creating a blank project, or was causing error when trying to call a project-object method (.store()) on it * fix: runtime error when adding two projects, using enter key. the name of the project is a blank string, and was either creating a blank project, or was causing error when trying to call a project-object method (.store()) on it * remove comments and spacing for clarity * add comment for clarity * timestamp projects on creation * rename as 'id' of project because it is a unique identifier * write getter for id. add id of project into its 'details' that can viewed id cannot be modified * remove id getter for project can just view id via viewDetails() method, which will be stored in localStorage * sort array of project names after filtering out inbox * retrieve the actual project objects (not just the names) from get go this enables us to grab the objects' id from localStorage. i decided not to reconstruct the project object as we're not writing to the project (and thus messing about with a private variable), just grabbing it and sorting the projects. if i want to be absolutely safe, then, in the future, i would create a getter for project id, reconstruct every project we retrieve * rename method for displaying projects for greater clarity * add variables from DOM that are required * create lookup object for svgs in screenController. update text content and inner HTML (being the svg) based on the project page that is being loaded * add .icon-container class to figures that wrap svgs in the sidebar. make svgs 100% easier to just replace the svg in certain circumstances using js * remove separate declaration of boolean * remove hash placeholders from anchors in sidebar. ensure that inbox is shown on initial load * retrieve the project object in screenController. add getProject method in app that essentially is just the localStorageHelper method i did this because i want app to be the interface between the helpers and the DOM (managed by screenController), rather than the screenController also importing localStorageHelper methods * utilise data attribute on the div that holds evertything in the nav to identify the right project because the <p> tag is nested so deeply, it is hard to go e.target.textContent type of way to extract that information via js to match * make the add project div a class rather than id makes it easier to select those links with _only_ .link as its class, at least according to stackoverflow * select all project links, including that for the inbox * attach event listener to every project link. add alert just to test functionality * select nav links that are 'inbox' or a project - excludes 'add a project' link in sidebar. add event handler for clicking on a project link. inside, as first step, we remove the .selected class from all of the links * clicking on the project nav link (including inbox) puts the blue highlight around it on the sidebar * clicking on a sidebar link for project (or inbox) runs the displayProjectPage function. at the moment, this function only updates the title of the page * make all anchors trigger pointer: cursor to welcome clicking. reduce nesting in html markup. display inbox page once tasks (the cursive icon on the top left) is clicked * highlight project in navbar in the function that displays the page this makes sense. if you display the 'page', you can argue the entire browser is the 'page' and thus what's in the sidebar should also be handled there * clicking branding opens up the inbox page * comment out all event listeners. remove cursor: pointer behaviour on branding on top left of nav * have clearing all styling of selected project nav link (including inbox) at the highest level of screenController.js so it can be hused within functions, espsecially displayProjectsInNav() which gets called often. clicking inbox does not work. these event listeners will probably need to be attached at the screenController level * generalise to a event handler for clicking all nav links (minus add project) * clicking branding or inbox now opens the inbox page * remove unused comment * When a user tries to add a new project but that project name already exists, display error immediately (#10) * add html element of error message * adjust gap in dialog for creating new project. adjust margin of error message * update font colour of error message * display error message for project name duplication only if there is _also_ a .error class in the error message * remove error being thrown for duplicate name when creating project inside of the project factory. reconstruction of project factory now removed too as not yet used. this will be handled in the app controller. * space out error message from the input in dialog * add and test making the border of the text field the warning colour if there is an error class the attaching of error class will be handled by js * return false for adding project if name exists. otherwise, return undefined * restore throwing of error in project factory (the most atomic object in what we're trying to achieve here). thinking here, is that we can 'catch' it in the screen controller * catch error thrown from project object level when there is a duplicate name and add error class list fo the children of the 'top' container (this is the input and the error message itself, to toggle its visibility) * if user has just typed in a project name that already exists (triggering error), focusing on the box will style it according to the :focus style (primary colour ring) * if user enters a duplicate project name for adding, the error will show when submitting. however, when user goes back to edit the input field, the error will disappear. restore previous behaviour where the error border around the input field overrides the focus effect * when dialog is closed, error is cleared too * pressing escape key resets the form, clears error message and not just closes the dialog * rename createProject module as it now only has one function * rename class for modal that adds new project for clarity * add input fields for task name and description when creating new task * add due date input that shows 'Due date' when not focused, but shifts back to date input type once focused by making the initial input type 'text', it allows there to be 'Due date' as the placeholder * add project dropdown with dummy values i haven't yet figured out how to generate these options yet (i might have to use screenController to generate) * extend removal of styles to other input types as well in normalise.css * update 'description' text as a placeholder, rather than as the value inside of the description * add asterisk before new task title to indicate it is required. compare this with the other non-mandatory fields * generalise styles of input fields. actually add a very light border around the input fields as the white on the lightest primary colour tone is not sufficient contrast * adjust select input field type padding the text inside of select field drifts further inwards for some reason * generalise styling of buttons. add further comments. * adjust flex container gap for modal to create new task. put due date and project selector on its own row using flex container * don't have add task modal open * add to-do comment * update folder structure, and break bigger .js files down (#12) * add to-do comment * rename css files and place them in /assets/styles * update folder structure with models, helpers and views models define structure and behaviour of projects and tasks objects through factories. helpers contains the localStorage helper functions used to interact with localStorage. App.js is the central controller, managing user interactions etc (non-UI-rendering logic). Views is the view of the application. if i need to, i can always create a components/ subfolder for each of the components (eg sidebar, header, main section) * switch to a controllers/ subfolder to hold app controller and screen controller in subfolders might do a barrel export * rename screen controller subfolder entry file as index.js for clarity and also reduce text when importing * update class to ensure styling of add project modal's button is correct * separate out addProject UI manipulation from screencontroller * add icons again for future use. break screenController.js down into more modules * add icons again for future use. break screenController.js down into more modules * fix incorrect import * Enable adding of tasks via a modal, stored in localStorage, then retrieved and displayed in DOM (#13) * update name of adding project flow on the screen (using modal) for clarity and avoid name clashing with .addProject() method in app * open modal on click of 'add a task' on the top right of every page. remove asterisk from placeholder field because it looks ugly * add comment for todo relating to error messages using :invalid starts the input off with error, which feels not that great as a user * generalise focus effects - put blue ring and box shadow (subtle) around the input field * add icons for urgency filled is used if the task is urgent. otherwise, we use outline * add and colour button for urgency. * use absolute positioning of the urgent button to have it in the center of the text input field. if the urgent button is toggled, then, the image is supposed to change. this last part needs to be hooked up to js which still needs to be done * task urgency is toggled in the UI, changing between outline and filled alert circle * an urgent modal has a border on the left * make task name and project name fields (for adding new tasks and projects) bigger these are more important i guess! * add addTask method to app controller this method will orchestrate everything BUT the UI on adding task. the UI itself is managed using Screen controller, specifically addTaskUsingModal() function * pressing cancel on add task modal closes the modal * add a bit more spacing above button groups in modals * add handlesubmit (event handler) for when an add-task modal is submitted * simplify addProject method * make description private attribute. creating a task only requires name in the argument * rename task name as task name to align with project name (no nameclashing because they're different objects anyway). update setters and details being viewed from task * update function to create task from JSON * ability to submit the form in the add tasks modal, and log the details of the newly added task * remove unused comment * use setters for urgency and complete instead of toggling this seems to make more sense when interacting with the ui * remove method for reconstruction for now * urgency and completion should take in a boolean value. if it doesn't take in a boolean value, just exit out (guard clause). users won't be interacting with these functions directly * set all properties other than dueDate in addTask (in aapp controller) need to test how dates work from inputs * select required inputs of form to create new task * create object in screencontroller, where keys of object are arguments for creating a task (in task object), and values are from the ui * set due date based on due date provided in form * add comment for clarity * add projectName as an attribute that we extract from the modal's form, and passed into addTask. handle blank dueDates * only export required functions from localStorage helper * remove unused helper functions * retrieve project. initialise several potentially useful variables for helper to store task into localStorage * avert error when reconstructing a project when the project name already exists. create a setter for id so that it can be updated when reconstructing. added comment for internal clarity * remove console.log statements. use 'retrieve' verb method in app controller for clarity * create getter for task's name as this can be used in helper when storing task * simplify adding and getting tasks. enable duplicate tasks in a project. add singular task object's details (this can always be called in a loop if required) keeps codebase simple * remove unused localStorage helpers. ability to store tasks into localStorage. rename project methods for clarity and cleaner syntax in appController * align method of task too * reset form for adding task, and close task after submission * update variable for projectDropdown in modal for adding task for clarity. for each project name, generate them as an option in the dropdown for add a task modal * have separate module for displaying tasks in the DOM, mcontrolled by screenController * reconstruct specific project being retrieved at the App level we do not want to do this at the DOM (screen) level as it isn't really related to the screen * update the way that we get (using getter) name of the project object that has been reconstructed * separate out function that generates (updates) the header of each of the project pages * write function that recreates a task from JSON (retrieved from localStorage). remove setter for name for now as not used this aligns with how the Project factory works as well * rename methods for tasks and projects for clarity avoids nameclashing, as we are now importing recreating task from json method into project in order to reconstruct the tasks at the most atomic level * update variable names to clarify when to use task objects and when to get the task details - split getter for tasks into two inside of Project * when a project is reconstructed from json, its composite tasks are also reconstructed in the recreateProjectFromJSON function * align variables and calls of task/project methods to enable tasks being stored as objects in project * realign variable naming to avoid issues when storing * interact with tasks in displayTasks module as task objects not as task details allows us to actually use the tasks' methods that we have defined in our factory * move all modules (each its own function) into displayPage subfolder in Screen * throw an error if setId method is called on project object if the project is not being reconstructed from JSON thought this was better than just using a comment in js * generate, from the top down, each 'article' that represents each task. completed the checkbox, task name. created unordered list that list items will fall under * remove getter for name of task as we can just instantiate its details using task.viewDetails() * loop through each attribute (key) of task details (object) and skip over name and completed name will already have been populated. same as completed * simplify html and add attributes that align with the properties in the task object in javascript (CamelCase too) so it is easier to leverage when looping through. make sure that all task attributes are aligned in center * skip over an attribute of task if the value is either empty string or false * remove console log statement that is now unused * store tasks' due dates in format YYYY-MM-DD if, when displayed, it needs to be reformatted, we will then use date-fn library in the DOM. but, converting it at the Task factory level, storing it, and then changing it back feels cumbersome, especially because no normal user is going to go looking through localStorage and checking the data in the console / Application tab of devtools. EVEN IF they do, YYYY-MM-DD is still easy to understand. * add svgs for task attributes as an object, global but only in displayTasks * simplify html markup by removing .task-attributes (which was a duplicate of selector for .task-attributes li anyway). create list item, add the attribute itself as a class name (not sure if this will be needed but doing it for now just in case we need to identify the element being generated to DOM), and add the svg as the inner html of the figure * add text content for task details. conditional if the attribute being looped over relates to urgency * write a function that generates a list of list items * display task items * display task attributes from localStorage. fix incorrect usage of key in SVGS object * update todos * reduce gap between tasks * fix issue with description not having an icon and the word 'undefined' being shown on the tasks * properly format due dates according to australian standards of dd/mm/yyyy * increase scope of formatting due date to also include styling the colour of due date and how it is shown is purely DOM (screen) at the moment, so it makes sense for it to be in displayTasks under Screen controller * style dates that are due today i couldn't have a separate function right now because for dates that are due today, the function needs to have access to the <li> element... i might need to come back to this. a workaround is to have a function that generates an object where the status (whether today, overdue, or future) is in there, as well as the formatted date * simplify formatted date according to australian * style overdue tasks * remove dummy task representing overdue * update names for clarity * after adding a project, that project's page is displayed * after adding a task, the page automatically reloads with all the tasks * clear every task before regenerating all of them, helping to avoid duplication, and actually showing projects' tasks when there aren't none mapped to them yet, fixes #14 * create subfolders for modals and nav inside of screencontroller better management of knowing where every file is * remove comments * do not display the newly created project page * rename modals screencontroller modules based on functions again for clarity otherwise there is a nameclash with adding projects and tasks in app controller * remove comment * ensure proper linkage * remove dummy tasks from html, including comments * prevent description field from being expandable by clicking and dragging from the bottom right corner of the <textarea> element * do not display the project that a new task was added to * build modal of task details (#18) * add task details modal in html, in open status so we can see it. add div for the left side of the modal (which is the first 'column' of the checkbox for marking the task as complete), and right side being all the other values and inputs for existing task's details. rename all ids to avoid nameclashing with the new-task-modal * generalise checkbox styling between checkbox on the 'preview' task item on the <main> part of the page, and the expanded task details in the modal * resize (make bigger in the modal) checkboxes that mark a task as complete * add comment for clarity * position left and right side of the task details modal form. add margin to the top of the checkbox to manually align * Adjust margin-top for checkbox to better align with task name. rename right side of the modal for task details to have more meaning (self-documenting) * Reduce gap and remove comment * create js module that opens then handles DOM events relating to the modal for task details * clicking on task element in <main> section opens up the modal * stretch fields. align gap with add task modal * reduce width of task details modal * reduce spacing of checkbox in task details modal * reduce spacing of checkbox in task details modal * increase font size of task name * reduce gap between task attributes * remove-comments * generalise handlers for task modals (other than submitting it) so these functions can be reused across add new task modal as well as edit existing task modal * ensure minimum height of tasks * closing modal with cancel button * show existing projects as options in dropdown of existing task expanded * adjust extra margin above button group * thicker border around checkbox in modal. add comment for clarity * generalise urgency styling of modal (orange border on leftside if switched on + svg icon for urgency going from outline to filled) to both add task modal and edit existing task modals * remove unused comments * give option for getProjects() in App Controller to get all projects, including 'Inbox' or not * rewrite html modal for task details in js so it is generated on click of the task object in <main> section (task preview) this is because of issues with attaching event handlers if it's just sitting in the html * add event listener for urgency toggle button when the task details modal is being generated * when a task details modal closes, it is also removed from the html avoids issues with selecting the right element for event handling. * remove section that held the task details modal, and align with other modals by adding directly to body element of html * clear error messages in a handler for modals that is generalised and can be imported * generalise clearing of form error messages and closing modal as handlers for modals, and imported into flow for adding projects * extend handlers relating to closing modal to modal for adding tasks * add close modal event listeners for viewing task details. remove the child * attach escape key press event listener to the modal itself, and not the entirety of the document to avoid clashes * remove event parameter as unused * store id as a property of tasks * add optional parameter for task factory that aligns with project factory in that there is a setter for ID, but only can be used when reconstructing from JSON * skip past certain attributes when generating a task div (in main section of page), including id * do not show new task's project if it is added there for future * remove old flow for console version of app * add diagram * stores projects in localStorage in the 'projects' key of localStorage. remove id from the details of project as this is already the key * write helper function that retrieves project by name * add retriever to get projects as objects, or aretrieve projects as an array * enforce uniqueness of project names by readding projectExists check from localStorage helpers, imported into project factory * get all projects in modal for adding task and viewing (expanding) task details * ensure correct helper function is called in app controller. remove comments * catch error on intitial load of app (when localStorage is empty) and return an empty array * rename task getter tasks, in the current design of the data structure, will be an array of task ids * check first if the project being stored already is a project in storage * fix -- adding new project does not replace all previous projects now * add new task's unique id to the array called 'tasks' under projects * inspect task details * add localstorage helper function that retrieve all tasks as objects * update diagram to add prefixes to ids to better distinguish tasks and projects from each other * update diagram to reflect design - we want projects to have a P prefix in its id, and tasks to have T prefix to better identify them. Inbox is going to just be 'inbox' for its id * check if task is existing because tasks is an array, we don't want to just be completely replacing the tasks array when storing - we will lose all of the other tasks. instead, we need to get the entire array, remove the task if it exists, then push it back * align the way that tasks and projects are stored * update recreation of project from json by adding that the recontsructed project should replace all of its tasks with what is stored in json * simplify storing of tasks * enable adding of task to inbox and other projects and properly storing into localStorage * display project names in nav. add attributes for id and name id is for future-proofing for when we allow for duplicate project names * throw error if duplicate project names are found * create getter for id of project so that it can be called in updateHeader for when user clicks on a new project page * update header of each projects page. we now try and leverage id of project instead of tasks because it is more unique * rename methods and variables in project trelating to tasks clearer that projects just store the more lightweight ids * write method for projects to get the tasks as objects because tasks are stored in an array of task Ids for project, this then retrieves the entire object (task) from the ids * fix -- error when an empty project is clicked from nav and attempted to be displayed. if there are no tasks mapped to the project, just return out of the methods * fix -- align naming of attribute of projects relating to tasks being task id and not 'tasks' anymore * refresh the project page you are on after you add a task, whether to that page or not * ensure ordering of projects in dropdown of modals align with the order in the nav to avoid confusion * fix -- was calling the old localstorage helper in check (also in localstorage helper) whether a project name already exists * have localstorage helper retrieve project by id id is the most unique identifier * at the app level, get the project by id * display page based on projectId parameter, not project name anymore * initially display inbox based on the 'inbox' project id * update data attributes of project link divs in nav. pass project id to nav link click handler instead of name simpler data attributes allow easier calling of those attributes' values when required * pass id of inbox in when clicking the branding in navbar * update hardcoded data attributes of inbox link * rename helper * simplify arrow function * move pseudocode * when checking whether project name exists, we remove parentheses with numbers inside, then trim the white spaces on each end, to confirm if the project name already exists * write setter for name of project * create project using their name, but now there is a suffix to help distinguish them * ensure that name is being reconstructed for projects. fixes issue where the project name was not showing on the header of the project page * add task id as data-attribute to the article element representing the task purpose is to be able to uniquely select that task, even if it has the same name * rename method for opening modal for given task. pass task id through viewing details of tasks, down to the generation of the specific task's modal for its details. at the moment, this hasn't really been utilised within the functions, but it is the best way to uniquely identify the task * instantiate app controller this is so that we can properly retrieve the task from localStorage * add getTask method in App yes, this is just calling the helper from localstorage, but i don't want any dom elements to be using the helpers - they should ONLY be interfacing with App * pass task object through to the function creating and displaying the modal for the particular task's details, rather than just the id this means we don't need to reconstruct the task from its id again at the displayTaskDetailsInModal level * restore helper function to retrieve a project object ((without its methods just yet) by _name_. this is because when a user is creating a task, they don't get to see the ID, so it can't really interface with the equivalent helper using id. names are also unique now, in that they will always have a suffix * give unique identifier to both tasks and projects (#22) * store id as a property of tasks * add optional parameter for task factory that aligns with project factory in that there is a setter for ID, but only can be used when reconstructing from JSON * skip past certain attributes when generating a task div (in main section of page), including id * do not show new task's project if it is added there for future * remove old flow for console version of app * add diagram * stores projects in localStorage in the 'projects' key of localStorage. remove id from the details of project as this is already the key * write helper function that retrieves project by name * add retriever to get projects as objects, or aretrieve projects as an array * enforce uniqueness of project names by readding projectExists check from localStorage helpers, imported into project factory * get all projects in modal for adding task and viewing (expanding) task details * ensure correct helper function is called in app controller. remove comments * catch error on intitial load of app (when localStorage is empty) and return an empty array * rename task getter tasks, in the current design of the data structure, will be an array of task ids * check first if the project being stored already is a project in storage * fix -- adding new project does not replace all previous projects now * add new task's unique id to the array called 'tasks' under projects * inspect task details * add localstorage helper function that retrieve all tasks as objects * update diagram to add prefixes to ids to better distinguish tasks and projects from each other * update diagram to reflect design - we want projects to have a P prefix in its id, and tasks to have T prefix to better identify them. Inbox is going to just be 'inbox' for its id * check if task is existing because tasks is an array, we don't want to just be completely replacing the tasks array when storing - we will lose all of the other tasks. instead, we need to get the entire array, remove the task if it exists, then push it back * align the way that tasks and projects are stored * update recreation of project from json by adding that the recontsructed project should replace all of its tasks with what is stored in json * simplify storing of tasks * enable adding of task to inbox and other projects and properly storing into localStorage * display project names in nav. add attributes for id and name id is for future-proofing for when we allow for duplicate project names * throw error if duplicate project names are found * create getter for id of project so that it can be called in updateHeader for when user clicks on a new project page * update header of each projects page. we now try and leverage id of project instead of tasks because it is more unique * rename methods and variables in project trelating to tasks clearer that projects just store the more lightweight ids * write method for projects to get the tasks as objects because tasks are stored in an array of task Ids for project, this then retrieves the entire object (task) from the ids * fix -- error when an empty project is clicked from nav and attempted to be displayed. if there are no tasks mapped to the project, just return out of the methods * fix -- align naming of attribute of projects relating to tasks being task id and not 'tasks' anymore * refresh the project page you are on after you add a task, whether to that page or not * ensure ordering of projects in dropdown of modals align with the order in the nav to avoid confusion * fix -- was calling the old localstorage helper in check (also in localstorage helper) whether a project name already exists * have localstorage helper retrieve project by id id is the most unique identifier * at the app level, get the project by id * display page based on projectId parameter, not project name anymore * initially display inbox based on the 'inbox' project id * update data attributes of project link divs in nav. pass project id to nav link click handler instead of name simpler data attributes allow easier calling of those attributes' values when required * pass id of inbox in when clicking the branding in navbar * update hardcoded data attributes of inbox link * rename helper * simplify arrow function * move pseudocode * when checking whether project name exists, we remove parentheses with numbers inside, then trim the white spaces on each end, to confirm if the project name already exists * write setter for name of project * create project using their name, but now there is a suffix to help distinguish them * ensure that name is being reconstructed for projects. fixes issue where the project name was not showing on the header of the project page * add task id as data-attribute to the article element representing the task purpose is to be able to uniquely select that task, even if it has the same name * rename method for opening modal for given task. pass task id through viewing details of tasks, down to the generation of the specific task's modal for its details. at the moment, this hasn't really been utilised within the functions, but it is the best way to uniquely identify the task * instantiate app controller this is so that we can properly retrieve the task from localStorage * add getTask method in App yes, this is just calling the helper from localstorage, but i don't want any dom elements to be using the helpers - they should ONLY be interfacing with App * pass task object through to the function creating and displaying the modal for the particular task's details, rather than just the id this means we don't need to reconstruct the task from its id again at the displayTaskDetailsInModal level * restore helper function to retrieve a project object ((without its methods just yet) by _name_. this is because when a user is creating a task, they don't get to see the ID, so it can't really interface with the equivalent helper using id. names are also unique now, in that they will always have a suffix * update diagram * rename parameter to clarify what should be passed in * add getter for name of task * update name of iterable for clarity on what is being iterated over. populate task name value in modal * write getters for every property of task. display the description retrieved from localstorage for a task when expanded nicer to have getters rather than calling .viewDetails().propertyname * populate project and due date project is populated by the current page project's name. i've done this so i don't have to manage having 'projects' as its own attribute for tasks which, at the moment, feels like a lot of overhead * if a task is completed, the checkbox in the modal is already checked * simplify setting of attribute for urgency button * if a task is urgent, upon opening, it is also urgent * remove unused import * Modify existing tasks' attributes, including project (#24) Completion _can_ be edited once you open up the task's details modal (and indeed updates localStorage), but not yet from the checkbox in the <main> element of the page - the task <article> elements. Styling is only partially implemented. These further tasks relating to completion of a task should be mopped up in #15 * create function in separate module called modifyTask.js, which is an event handler function that gets called when the form in an task details modal is submitted * prevent default behaviour of submitting * pass in task object to specify * begin writing modification of tasks at the app controller level technically this is correct, because we're not trying to manipulate the DOM just yet * ensure tasks are rebuilt to include methods in original factory at the appController level * write check to see if project name has changed. if it hasn't, just get all the stored tasks and filter out the current task from it project name changing means that we need to touch two projects. if not, then we don't even need to touch the projects, because projects only have a reference to the tasks via the tasks' ids! * add setter for name of a task keeps it private, rather than exposing the .name... that would render the getter useless! * use setters to update task attributes * store task once modified. commented out project HasChanged check because it was wrong * update diagram representing data structure of localstorage by adding a projectId attribute to tasks this means avoiding having to pass through an additional argument into app controller that pulls the current project from the dom, making the parameters clearer that it is the new task objects' attributes. it also avoids the previous way in the console version where there is a helper that scans through all of the projects to find the one with the task. if there are 100 projects, this is really inefficient. * add mappedProjectId attribute to task object factory and add comment at the moment, a task must have a project (it can't be projectless). a task cannot have more than one project. by default, the task goes to the 'Inbox', ready to be categorised into a project or not at all * add projectId to viewDetails() method of task so it is stored in localStorage. have a method called 'getProjectObject()' that returns a reconstructed project object this aligns with how the project also has a method to reconstruct all of its tasks from the array of task ids in each project. ?? question: by importing project and task methods into each other, does this make it too tightly coupled?? * simplify retrieveProjectNames localStorage helper into a single line (shorthand) arrow function * have localStorage helper to retrieve all project Ids * begin writing setter for project id. return a console.log statement if the project id does not exist * complete setter for project id and expose in return of task object * ensure project id is also passed through and set when task is being recreated from JSON * hide project id from the task divs * at the appController level, if you're adding a task, you pass in the project Id and not the project name project id is more unique. this is to future proof the very likely scenario when a user wants to change a project name. i feel this is the most future-proof way by using the most unique key for a project. from the DOM, we can always get the project ID too using data attributes, which should be coming in the next few commits * remove unused imports * instantiate app controller on taskModalsHandler instead of reaching deeper into the layer that is localStorage handlers * update variable name for clarity. restore recreating project at app controller level * properly call createProject for inbox and actually give the inbox a name * make sure that the 'value' of the <option> for dropdown for projects is the projectID and not the projectName * remove unused console log * write getter for task's project id (rather than the project object) so that this can be called efficiently in displaying an existing task's project in the dropdown * remove unused comment * do not submit the form in the modal that display details of task. instead, put event listener on the button for save this is because i can't pass both an event ('e') parameter to stop default action of submitting the form, which isn't the form, AS WELL AS the task object that the modal is referring to. i guess the only other way is putting the task's id on the <form> element as a data-attribute, so that i only need the 'e' parameter (and do like e.target.dataset.id or something). BUT, that would mean i need to retrieve the task, reconstruct it (both done in method in appController) when modifying a task... on the balance and thinking out loud, it just feels more cumbersome, but is an option in the future if i want to align the behaviour of the submit/save buttons on the other modals. the other downside is that i need a separate event listener on the enter key to do the same thing as pressing save, which i'll bear for now * gather all required 'updated' task details in an object from DOM in modifyTask.js * test whether project has changed once save button is clicked - success! * test whether project has changed once save button is clicked - success! * close the modal after submission, and refresh the current project page * add comments as next steps on how to handle when project has changed * add method to project object that removes task otherwise, we'd have to replace task with an array that has been filtered anyway in app controller. better to just do it at the source tbh * if project has changed, remove the id of the task from the old project and store the project, then add the task id to the new project and store the project, then set the project id to the new project id * remove unused comment this will be managed through github issues * pressing enter key on keyboard on task details modal open is the same as clicking the save button * remove unused comment * enforce having inbox first if inbox is not excluded * fix issue where the inbox project is at the bottom, m of dropdown of taks modals * enable clicking of checkbox. prevent clicking checkbox firing opening of the modal (event listener on the <article> parent element that represents at ask). this was done by adding a event.stopPropagation on the _div_ of the checkbox, and not the checkbox itself * write app-level method to mark a task as completed and store into localStorage the updated status * after checking the checkbox, the entire page is reloaded to see the updates in styling however, this has caused the checkbox itself not being checked for some reason, which i will need to fix * if a task is completed, then the checkbox is checked * add comment for clarity * make border colour transparent for completed tasks * ability to mark task as completed from the main page, and updating styling accordingly (#25) * fix issue where the inbox project is at the bottom, m of dropdown of taks modals * enable clicking of checkbox. prevent clicking checkbox firing opening of the modal (event listener on the <article> parent element that represents at ask). this was done by adding a event.stopPropagation on the _div_ of the checkbox, and not the checkbox itself * write app-level method to mark a task as completed and store into localStorage the updated status * after checking the checkbox, the entire page is reloaded to see the updates in styling however, this has caused the checkbox itself not being checked for some reason, which i will need to fix * if a task is completed, then the checkbox is checked * add comment for clarity * make border colour transparent for completed tasks * write empty body for function to deleteTask() in appController * recreated modal for task details in wireframe to design ui for deleting task. however, i did not continue. i believe that the same delete pattern should exist between tasks and projects alike, where, on hover over the div/article, you can see a bin or cross icon to indicate deletion. then, triggering deletion workflow * update wireframe slightly. update naming of variables for displayTasks and class of task article css class for clarity this is because, at the moment, i intend there to be an even more 'right' div to hold the trash can div * create binDiv to be a div container for the bin svg * remove zindex on checkbox as unused the issue relating to propagation was fixed in js through event listeners - zindex doesn't actually stop propagation of event handlers * use flexgrow on the details (middle part of the .task article) to push checkbox all the way to the left, and what will be the trashcan all the way to the right * change to button thinking this is what we need to mask it with a svg in css, just like with the urgency * fix class adding for button for deletion. remove background colour * add hover effect, padding and transition for hover effect (background colour change on hover) for delete button * delete btn appears when the task article is being hovered on * add animation for hover over article to display the delete button * round out delete button * add trash icons * add mask image with outline trash icon, adjust hover effect of the button itself (just darken), use our --dimmed colour for consistency * clicking the trash can changes the icon from outline to filled * update existing event listeners use mousedown instead of click because more responsive (thank you john carmack, i'm with you 100% for situations like this). simplify to a single line arrow function * clicking bin button does not also open the modal (event handler effect when you click the parent container (.task article) * adjust positioning of bin button to be a bit further out to the right * rename for clarity. move event listeners down into its own section in code for easier maintainence * have the cancel button of all modals to the left, and proceeding to the right. also remove modal handlers for errors in modal as we now handle duplicately-named projects. i agree with the discussions/answers here: https://ux.stackexchange.com/questions/1072/ok-cancel-on-left-right * rename classes for clarity. add html elements to modal * style delete button * style delete button and align size of the modal heading with other modal's project and task names (where appropriate) * move text for deletion confirmation modal into the <form> element, which already has css on it to make it into a flex container. adjust gap (reduce) as there are far less item in this modal compared to the others * handle deletion of task in its own js module called handleDelete * generate delete confirmation modal from js i * close modal on clicking of cancel button in delete modal. append modal to document body, but then remove it when it is closed * log details, close modal and display the current page (project) * add method in task object that removes itself from localStorage i feel it is better to have it here, aligned with the .store() (stored into localStorage) than in the helpers * remove task both from the project and also from localStorage tested on both inbox and another project * simplify handleDelete js module by removing single line arrow function and merging as part of generateModal we can separate out if we want clarity, but this reduces linecount * remove console log statements. simplify arrow functions to one liner * remove error message from html * add comments into app controller for clarity * enable ability to rename project. fix sorting of projects in chronological order of creation (oldest on the top) (#37) * add comments into app controller for clarity * write renameProject method in app controller * Prevent duplicate names in project (#36) * add comments into app controller for clarity * write renameProject method in app controller * move DOM manipulation of nav from displayPage (which is referring to the main part of the page (<main> element) to the nav side. update paramater names - we are now using id of projects in nav, not the name) * clear out unnecessary part of html markup for each page's header that gets populated anyway by js * simplify updateHeader.js * reduce font size of header (page title) * use specific selector for page title * make the page title have an id (good practice for input fields iiuc), and populate the value in updateHeader when you click onto a new project page * make page title bold * rename class of page icon. remove box shadow on focus * adjust font colour, add border when input field is focused. once clicked, all text is highlighted highlighting all text is copied from Microsoft Tasks. it just allows the user to delete the whole project name more easily, which is a nice shortcut! * adjust padding of input field. reduce font size of heading. adjust margin and gap so that there's alignment with task below * project name can take up the whole space between the icon to the left and the 'add a task' anchor link to the right covers for when the project name is super long * update selector to be more specific and self-documenting * move event listener into js there will be other event listeners too - easier to have all in one place for maintainability * disable header change if it is inbox page * on click of the page title for editing, the icon is hidden * once blurred (clicked outside of the input field), the icon returns * prevent renaming of inbox * remove unused code / comment out for now * add id of the project page the user is looking at as a data attribute to the #page-title * add onclick event highlighting all text of project name in html * have separate module for handler for project name changing * remove try/catch in adding project modal because we now enable duplicate names (suffix get added). add module in helpers/ folder to check for duplicate project names and add suffix if required * update variable names in module for adding suffix to duplicate project names * update events to mousedown see john carmack * add event listener to blur of project name change * only run blur event handler once can always remount it once user clicks the input again * if renamed name is just empty space, or is just the same as old name, then have old name in the title * add suffix to the renamed project name if it is a duplicate by calling the helper * set the name, add it to the handler for project name change, then store into localStorage * remove console.log statements * ensure correct use of cleaned project names rather than just unclean project names * remove console log statements * return cleaned project name if it is not in storage * remove unused return statement * display nav projects once a project is renamed * remove console log * simplify sort - revert to previous for app controller * properly sort the projects by removing the first letter of the projects' ids, and then converting them to numbers AND THEN subtracting. FIXES #30. * remove duplication of methods in app controller might have been a version control issue that wasn't picked up by git * put focus onto the input field by waiting. fixes #39 this is not the best, but i think the issue is that the modal isn't fully loaded yet before having its text input be focused on. * focus on task name field when creating new task this is the only mandatory field, and is also the first one that appears at the top, so makes sense to focus on it * remove unused console log statement. test if pageTitle element is being properly selected pageTitle element will be very useful in determining the project id that the user is currently on * pass in the current page project id from the screen controller level when calling the event handler for when a user clicks on the addTaskBtn * Revert "pass in the current page project id from the screen controller level when calling the event handler for when a user clicks on the addTaskBtn" This reverts commit d9f82a2b7fca2f10966b9d3fe1d3bd9e8bd22017. * make page project id based on page-title rather than nav this makes more sense and more aligned to users - they would look at the page title and not what navbar is doing for what page they're on * remove unused import * add a one-time event listener in the updateHeader.js for add a task, beacuse the state of what project id the page is currently on can be passed there when i tried to do this too high up, at the screenController level, it didn't work, because it didn't acutally update the project id as i navigate through the pages, because the event listener was attached one time at the screenController level. it needs to be dynamic as the pages change * remove one time event listener because, if a user clicks to add a task, cancels it, they won't be able to open the add task modal again witho…
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
when a user clicks on a task div in the
<main>
section (depending on the project / Inbox (project-less tasks)), the details of the task expandsthis will eventually allow users to edit those fields (#17), as well as delete those tasks (future issue / PR)