fac-17 / cgko-week-4

Simple postcode autocomplete :checkered_flag:

Postcode Autocomplete 🏁

Team

Tony😋
Christine😉
Gigi😌
Francesca😀

Aim 🎯

Our aim was to build a simple postcode autocomplete app using Node.JS, HTML and CSS.

Group Mantra

1. Our focus this week is on everyone learning the most rather than having the most fabulous project
2. Pair programming - ensure everyone pairs up with everyone at least once
3. Use 20/20/20 - if a pair has not found an answer after 20 min we can open the problem up to the team and do a mob

The Project

Features & APIs

1. We use an autocomplete API link

2. Autocomplete dropdown: https://www.w3schools.com/howto/howto_js_autocomplete.asp

3. Listen to input value change: https://stackoverflow.com/questions/26946235/pure-javascript-listen-to-input-value-change

4. Initially we set up a dummy JSON file and made an API call from the client side to our own backend dummy data. This was successful, however we were unable to make an API call from our server to the Postcodes API, hence we just enhanced our app by making the API call from client side to the Postcodes API.

Task List

Day 1

• Deploy to Heroku as a group (+ link to our repos)
• App architecture mock up
• Set up skeleton files
• Agree on file structure for server side code

Day 2

• Decide on new task list + distribute to pairs
• Access object from server side and populate dom dropdown
  • Event listener on key_press and re query the object
  • Use query string to to concatante to longer query string and parse in order to return updated object data (irrelevant as inconsistent with app architecture)
• Create pure functions + tests (irrelevant as inconsistent with app architecture)
• Create dom functions
• CSS Styling
• Put in favicon
• Ensure file structure is good and maintainable (continues to work)
• Keep an eye on Heroku deployment
• Keep Readme updated

Requirements

• Website that enables users to quickly find and select words from a list of suggestions, as they type.
• The list is dynamically generated from a pre-populated list of values (i.e. a dictionary file), leveraging searching and filtering.
• A large data file is required to search through - consider the best data structure for this (e.g. .txt or .json).
• Consider how implementation affects user experience and web performance (e.g. time to load and search through the data file).

Strech Goals

• API call to postcodes.io

What we have learned

• There is a HTML5 tag that is used to provide an "autocomplete" feature on elements. Users will see a drop-down list of pre-defined options as they input data. (carefull! - cant be styled) https://www.w3schools.com/tags/tag_datalist.asp

• We now understand the connection between server, router and handler functions

• How the backend and frontend communicate

• That API calls are best placed on the backend, which allows the client to continue interacting with the browser while the API makes its call

• How to deploy to Heroku!

• Listen to input value change: https://stackoverflow.com/questions/26946235/pure-javascript-listen-to-input-value-change

• How usefull mobs are with unfamiliar topics

Challenges

• Making an API call from the backend is hard!

• Maximal confusion on how back and front-end communicate

cgko-week-4's Issues

Refactoring handle.js 'extension'

I think, this can be a simple one :)
It would be interesting to see if it's possible to refactor the code of your handler.js file when you re-adjusting the variable 'extension'/'extensionType'. For e.g.: Taking it out of the handlePublic function, to put it in your global scope, so you can use it everywhere (have a look in our code, maybe it can help if what I say isn't super clear ^^)

Modules require modules and not use them

handlers.js requires querystring but never uses it, which is confusing.
Maybe either use it or remove reference to it

Datalist repitition

Good job using the datalist element!

But you may want to look into clearing it once the input is updated so that it does't keep adding results from previous inputs

Good job team CGKO! 🤟🏼

Well done this week! You've gotten through it!

I know from my experience from this week is that it was definiately a learning curve. It has scarred me.

If you do find time to add more post codes that'll be cool (feeling a lil left out here in SE 🥺)

Server running message is showed before it starts

server.listen(port);
console.log(`server up and running on port: ${port}`);

At the moment what it does it starts binding the port, then you outputs the message, then it starts the server, which can throw an error, so the message is premature.
Easy fix is to put the message inside the callback:

server.listen(port,()=>{
 console.log(`server up and running on port: ${port}`);
});

Accessibility

Just run the Audit in the console and that's what I found:

Maybe focusing on these which seems to be the most important?

1. Background and foreground colors do not have a sufficient contrast ratio.
2. Form elements do not have associated labels

Love the links in the README.md

Very helpful to have links to the research you've done!

404 Page not handled

Currently any incorrect url path is displaying your postcode.json file and not your 404 message. You may want to look at how you are determining any "wrong" paths in your router and possibly how you are handling errors in your handler.js file

Codebase still has commented out code and console.logs

When the project is in production mode, it would be great to remove them.

Commented out code

Saw a couple of commented out code, it would be good to remove them once you no longer need them as well as some console logs you may not need anymore to keep your code from getting cluttered 👍

Great picture in README: frontend vs backend

I'm learning with metaphors and this one is really helpul:
Backend is what you don't see unless you peek (but don't need to use the product), it's often more messy and complex. Frontend is what matters to the user and needs to be pretty!

const and let used very consistently

I like that you put effort into making your const and let used approprietly. Not a single ugly var in sight! 👍

Love how you used destructuring to import the handler functions

const { handleHome, handlePublic, handleQuery } = require("../src/handler");

cool stuff 👍

test.js

No tests in the test.js folder, but i guess you know this already!

Mobile

Well done on using flexbox!
Maybe, adding a @media query for mobile / applicable for device under 320px to have something more centered?

package.json test script has wrong path

It's a simple omission I presume: tape will look in the main dir of the project, but should look in test dir. Even if test.js is empty you might want to just add src/ in front of you tape path.

Placeholder placement

Just a lil thing I saw in your html file is that you put your placeholder text within your datalist node I think you may have meant to put it in the input node so that it will show up in the input box. Alternatively I saw you had a label node for your input but it was empty, it's always good to include some text to help the user know what is to be expected of them to do for that input box.

queryString is not being encoded before being sent as get request

in your index.js file(client side)

queryString is being defined as

let queryString = input.value;

and its directly sent to the server in a get request

xhr.open("GET", queryString, true);

the problem here is that urls only allow certain characters.
forbidden characters must be encoded into their hex equivalents.
(refer to week4 research, I have mentioned url encoding)

there is a convenient method encodeURIComponent() that will take your queryString and encode it in the correct format.

let queryString=encodeURIComponent(input.value)