davidecarvalho / brazilian_states Goto Github PK

Add regions feature

• Get a list of regions
• Get one region with all its states
  • Get one region with all its states, and each state with its cities within
• Get the region based on the name of the state
  • Get only the the region name
  • Get only the region name with its states
  • Get only the region name with its states and each state with its cities
• Get the region based on the name of the city
  • Get only the region name
  • Get only the region name with its states
  • Get only the region name with its states and each state with its cities
  • Get only the region name with the name of the state that this city belongs

Check if promisifying intern data flow will increase performance
Promisify memoization checking
Promisifying memoization add
Promisifying intern method to find the data (not memoized data)

Now a days, memoization is just copy-paste code shared between all the functions. Transforming it into a decorator should be the best option

Cria um arquivo na raiz do projeto chamado .gitignore
Adiciona uma linha com node_modules
Depois remove do histórico:

git rm -r --cached node_modules
git commit -m "Remover as dependências do repositório, closes #2"
git push origin master

Since we are using TS now, I started to realized some things:

• multiples returns are not good. It just make documentation worse and it's worse for the developers to know right away what is current type of the variable
• It's better only to return the full json instead. With es6 destructuring it's not that hard to get the wanted value

So I'm taking off shouldReturnEntireJson and it will always return the entire json.

Cache the results to increase performance if the method gets the same parameter multiple times.
Since the range of the results is always the same, memoization sounds like a good thing

When using this lib, the dev can accidentally put the city name in a way it's not totally equal to the json name (like it's in uppercase, or in lowercase)
Make the lib smart enough to normalize it before starting to find, this way the dev will have more ways to find it.

• Normalize case
• Normalize accent
  Maybe normalize special characters, if it's too hard, can be done on a later time.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore(deps): update dependency documentation to v14

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency ansi-html to 0.0.8 [security]
• chore(deps): update dependency parse-path to 5.0.0 [security]
• chore(deps): update dependency nodemon to v1.19.4
• chore(deps): update babel monorepo (@babel/cli, @babel/core, @babel/polyfill, @babel/preset-env, @babel/preset-typescript, @babel/register)
• chore(deps): update dependency chai to v4.3.7
• chore(deps): update dependency copyfiles to v2.4.1
• chore(deps): update dependency tslint to v5.20.1
• chore(deps): update dependency typescript to v3.9.10
• chore(deps): update dependency nodemon to v2.0.20
• chore(deps): update dependency nyc to v15
• chore(deps): update dependency typescript to v4
• chore(deps): update jest monorepo to v29 (major) (@types/jest, babel-jest, jest)
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Npm packages should not contain much dependencies. Putting the webservice inside the npm package only for the purpose of "if you need it, there is this option too" is not a good idea.

Maybe separate into two repos, this way the package will not have unused dependencies

I think the reverse path can be done.
Giving a city name, returns the states.

Cache the results to increase performance if the method gets the same parameter multiple times.
Since the range of the results is always the same, memoization sounds like a good thing

Right now, memoization is made on demand, in other words, if you make a call for a city or a state, it will be cached so consecutive calls can be faster.
But, and if the dev wants it already cached? Creating something like ‘’eagerMemoization()’’ sounds nice.

• Create eager memoization, so the lib can be started and cached right from the start, instead of beeing on demand.

Flow acabou não sendo uma boa opção. Ambiente muito lento, tooling ruim e pouca comunidade não fazem dele uam boa opção, trocar para TS talvez seja melhor.
Provavelmente usarei TS com Babel, porque quero apenas a tipagem e Babel consegue me ajudar mais porque tem mais features disponíveis.
Usar TSC apenas para gerar arquivos .d.ts