thedarkflame / housingenrichernl Goto Github PK

At present the applyEnrichment function is hardcoded to handle each source.

Making this generic would reduce the amount of modifications needed to the function each time a new element is added, as well as keep node text processing local to the function that generates it, instead of being spread across multiple functions

Problem:
At present Kiwi browser + violent monkey yields a "issue getting label" for all results, but the same issue does not exist in desktop based browsers.

Goal:
Get userscript working correctly on all platforms

Goal:
add support for kamernet.nl

notes:
It looks like most/all listings do not specify an address, however it may be possible to scrape the lat+long. Thus dependency: #1

Notes:
search for "HomeRadiusIconblue.svg" in debugger > search to find part of code that adds the marker at the lat+long.

Problem:
At present, address parsing is good, but sometimes fails to pick up valid addresses because they are formatted a little odd.

Goal:
Add more flexible/reliable parsing of addresses

Problem:
At present, only the Dutch pages are enriched (funda and pararius), it is necessary to apply enrichment to all other languages

added eslint, now there are a bunch of issues. These all need attending to.

All huurcommissie rulings are recorded, it would be useful to indicate if a property has a track record of rulings.

https://checkjeprijs.huurcommissie.nl/over-de-huurcommissie/uitspraken

Problem:
certain search queries on eponline fail when the address is correctly listed. This happens for one of two reasons:

1. The address is not properly matching the eponline format
2. There are multiple pages of results, at the moment only the first page is being processed

Goals:

1. Detect when the page indicates "Er is geen registratie gevonden." and distinguish this from when there are results which didn't match
2. handle a broader set of matches.
3. if match fails, offer set of buttons containing all possible matches/ or just list all matches densely in the enrichment

Initial test cases:
3051GK 89a -> fails
1314CG 1 1404 -> fails (but 1314CG 1 works)
3012EG 119D -> no reg
1354AC 100 4.03 -> weird listing address, but exists
9743AA 141 267 -> 512 results
2245BH 25 Type D -> weird listing address, many results, likely exists

Problem:
At present, enrichment is only performed on the search result pages.

Solution:
It is necessary to also include support for the individual listing pages themselves

Problem:
Many listings have missing address information

Proposed Solution:
Attempt to guess address based on Lat+Long using Google maps or GEOAPI

notes: The lat+long should be obtainable from the map in each listing as they all indicate the location of the housing on their maps.

Useful links:
https://developers.google.com/maps/documentation/javascript/geocoding#ReverseGeocoding

Add builtin checking of javascript code using eslint via github actions

This should be done according to the documentation

name: "ESLint analysis"

# Run workflow each time code is pushed to your repository and on a schedule.
# The scheduled workflow runs every Wednesday at 15:45 UTC.
on:
  push:
  schedule:
    - cron: '45 15 * * 3'

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      # required for all workflows
      security-events: write
      # only required for workflows in private repositories
      actions: read
      contents: read
    steps:
      - uses: actions/checkout@v3
      - name: Run npm install
        run: npm install
      # Runs the ESlint code analysis
      - name: Run ESLint
        # eslint exits 1 if it finds anything to report
        run: node_modules/.bin/eslint build docs lib script spec-main -f node_modules/@microsoft/eslint-formatter-sarif/sarif.js -o results.sarif || true
      # Uploads results.sarif to GitHub repository using the upload-sarif action
      - uses: github/codeql-action/upload-sarif@v2
        with:
          # Path to SARIF file relative to the root of the repository
          sarif_file: results.sarif

Goal:
To provide better information about the registered information of the property, particularly, the WOZ value, and size of property

Proposed Solution
scrape data from wozwardelocket and/or bag/bag API and integrate into results

At present, calling getToken() multiple times will yield multiple calls to eponline to get the token. This is an undesired amount of network traffic, and restricts the design pattern.

We should instead implement a method that will cache the promise result, and perform only a single request. An idea would be the following:

https://www.jonmellman.com/posts/singleton-promises

Goal:
To add a basic calculator which guesses at what a range for rental amount should be for the property based on known data (energy label, size, woz), and a range, as well as whether it should fall into the regulated or vrij sector.

and allows for user to select some input for certain things to refine the range.