Code Monkey home page Code Monkey logo

adventurelookup-frontend's Introduction

AdventureLookup

Repository of AdventureLookup, a search engine for tabletop adventures. AdventureLookup was originally proposed by Matt Colville in this video.

Branch CI Code Analysis Link
master Build Status codecov https://adventurelookup.com
dev Build Status codecov https://dev.adventurelookup.com

Contributing to Adventure Lookup

AdventureLookup is an Open Source project. You do not need programming experience to contribute to the project! Please read the CONTRIBUTING.md file for more information on how to contribute.

Setting up a development environment

We are trying to make contributing as easy as possible by providing the Gitpod and Vagrant setups described in this section. If you run into any issues while setting up your development environment, please let us know by opening an issue.

To get you up and running quickly, you have three options to set up your development environment:

  1. Gitpod online IDE
  2. Vagrant with VirtualBox
  3. Vagrant with Docker

Using Gitpod is by far the simplest approach: All you have to do is click the following button and sign in with GitHub. A VSCode-based online IDE will spin up with all dependencies preinstalled. The rest of this section is only relevant when using Vagrant.

Gitpod Open-Online-IDE

If you don't want to use an online IDE, but instead use your own editor, you should use Vagrant and either VirtualBox or Docker to start up a VM/container with all the dependencies preinstalled.

Using VirtualBox is recommended if you have are using Windows without Hyper-V available/enabled. In all other cases, Docker is recommended and faster.

After downloading and installing Vagrant and either VirtualBox or Docker:

# Clone the repo to your local machine (this is readonly; you need to fork if you want write)
git clone [email protected]:AdventureLookup/AdventureLookup.git

cd AdventureLookup

# Create and provision the VM
# This takes quite some time on the very first start

# If you installed Docker:
vagrant up --provider=docker

# If you installed VirtualBox
vagrant up --provider=virtualbox

Execute the following commands to finish the installation:

# Log into the VM
vagrant ssh
# You should be inside the /vagrant folder.

# Install PHP dependencies
composer install -n --no-suggest

# Install Frontend dependencies, can be run outside the virtual machine
npm install

# Setup database (confirm with 'y')
php bin/console doctrine:migrations:migrate

# Create Elasticsearch index
# This command will log a warning when run for the very first time.
# You can safely ignore it.
# WARNING   [elasticsearch] Request Failure: ...
php bin/console app:elasticsearch:reindex

# You can either generate random adventures or load real adventures from adventurelookup.com.
# Please note that loading real adventures might not always work, since the development version
# might expect a different API response than the version on adventurelookup.com provides.
# In addition, adventures fetched from adventurelookup.com don't include change requests or reviews.

# Either load random adventures (confirm with 'y')
php bin/console doctrine:fixtures:load --fixtures src/AppBundle/DataFixtures/ORM/RandomAdventureData.php

# Or load real adventures (confirm with 'y')
php bin/console doctrine:fixtures:load --fixtures src/AppBundle/DataFixtures/ORM/RealAdventureData.php

# Re-create the search index after loading adventures.
php bin/console app:elasticsearch:reindex

You can execute the following command to create dummy users:

# Creates 'user', 'curator' and 'admin' users, all with password 'asdf'
php bin/console doctrine:fixtures:load --append --fixtures src/AppBundle/DataFixtures/ORM/TestUserData.php

If you didn't use Vagrant but an existing MySQL database, adjust the app/config/parameters.yml file to match your database credentials.

Running the application

# Start Symfony development server on port 8000 to run the application
# Must be run inside the virtual machine you used `vagrant ssh` to get into earlier
php bin/console server:start 0.0.0.0:8000

# Start webpack to watch changes to assets and recompile them
# Can be run inside the virtual machine or outside of the virtual machine
# If run inside the virtual machine:
npm run dev-server-guest
# If run outside the virtual machine:
npm run dev-server-host

# Wait until you see 'DONE Compiled successfully in XXXXms' (may take a few seconds)

The application is now running at http://localhost:8000. ElasticSearch can be accessed at http://localhost:9200.

Running tests

Tests use PHPUnit to run. There are three testsuites, one with unit tests, one with functional tests and one with browser tests. Unit tests can be executed like this:

php vendor/symfony/phpunit-bridge/bin/simple-phpunit --testsuite unittests

Functional tests can be executed like so:

php vendor/symfony/phpunit-bridge/bin/simple-phpunit --testsuite functional

Browser tests require Google Chrome with remote debugging enabled as well as the application running in the test environment. To do that, execute bash scripts/prepare-browser-tests.sh once before executing the tests. There is no need to call the script again until you reboot. Then execute the following to run the browser tests:

npm run build
php bin/console cache:clear --env test
php vendor/symfony/phpunit-bridge/bin/simple-phpunit --testsuite browser

Debugging

If you want to dump the contents of a variable, the simplest way is to call dump($var). dump() is a function provided by Symfony. The result is displayed in the web debug toolbar.

You can also debug your code using XDebug by setting breakpoints.

  • For Gitpod, select "Debug" in the left toolbar and then run the [gitpod] Debug PHP Server task.
  • For Vagrant+VSCode, install the PHP Debug extension and run the [vagrant] Debug PHP Server launch configuration.

Then set a breakpoint and refresh your browser. The code should halt at the breakpoint. You do not need to install a browser extension to enable XDebug.

Ports used in development

Port Forwarded to host machine Purpose
3306 no MySQL
5900 yes VNC server (see scripts/prepare-browser-tests.sh)
8000 yes Application dev server
8001 yes Webpack dev server if run from within Vagrant
8002 no Webpack dev server if run from outside Vagrant
8003 no Application test server
9000 no * XDebug
9200 yes ElasticSearch
9222 no Chrome Remote Debugging

* debugging from your host works without forwarding the port, since XDebug connects to your host (in contrast to your host connecting to xdebug).

Tools used

  • Ubuntu 18.04 as the server
  • MySQL 5.7 to store the adventures
  • Elasticsearch 7.16.0 to search the adventures
  • PHP7.4 to run the application
  • Symfony 3 as the web framework
  • Composer as PHP package manager
  • Node.js 12 and npm 6 for frontend package management
  • Symfony Encore / Webpack for bundling frontend assets

Running the application in production

For information about server configuration, checkout the Symfony guide on server config. Make sure to read the Symfony guide on permissions if you run into permission problems.

You should configure your websever to set never-expiring cache headers for the /assets path (located in web/assets). Example Nginx configuration:

location /assets {
    expires max;
    add_header Pragma public;
    add_header Cache-Control "public";
}

adventurelookup-frontend's People

Contributors

brehaut avatar exote avatar solarswordsman avatar thewanderer41 avatar thradok avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

adventurelookup-frontend's Issues

Initial details view

Once a user has found a list of candidate adventures, we need to allow them to view the full details. This view will also need to be accessible by URL to allow users to link to it from other sites.

  • Display intrinsic details of the entry.
    • Subcomponent per field type (short text, tag, long text, numeric, range, ...)
    • Coordinate with design team to determine layout
  • Display user defined details of the entry.

This task has few checklist items but will entail a fair bit of work getting all the bits in.

Depends on #5, #6

Add fetch polyfill

We'll most likely be doing plenty of AJAX calls and XMLHttpRequest is somewhat verbose and clunky to use. The new fetch API is simpler to use and utilizes Promises. Shockingly, Internet Explorer doesn't support support it, which will require a polyfill.

Remove hash (#) from urls

Without some server integration it's not possible to remove the hash from the URLs used on the front end up before users start bookmarking things.

Once the front end is part of the development docker image we can set up url rewriting and the appropriate dev server mechanism to allow proper URLs

It's important to do this because the hash exposed implementation details about the front end which could make it harder for us to change imp in the future.

Depends on #3, #5

Android web app installation

Users may wish to install the site into their mobile device of choice as an 'app'. To support this we need all assets for all android device sizes and metadata configured correctly.

Consult googles latest documentation for details

  • Icons
  • Startup Images
  • installation metadata and manifest

Work with design team to determine whether we want full screen or browser chrome for installed apps. Do what seems appropriate for iOS separately from Android.

Icons and startup images should be based on site style and Alex Moon's hexagon/magnifying glass icon designs. See documentation wiki for visual style guide.

Depends on #11

Search middleware skeleton

Search is a major component of Adventure Lookup. The project will need middleware between the UI and backend APIs to coordinate requests and provide fast responses from caches.

This infrastructure will support all the different UIs users may use to search that may be built:

  • Simple search
  • Advanced search with a query builder UI
  • Advanced search with a parser UI

Tasks:

  • Define the schema for query messages to be sent to the server. Consider https://brehaut.net/media/files/search-proto/ as a starting point.
  • Skeleton web worker to act as middleware (dummy data initially, then pass through):
    • Build task for worker scripts.
    • Class to wrap up interacting with the worker for UI code to consume.
    • Messages that the middleware needs to support:
      • Search results for a given query.
      • All tags for a given tag stem across all facets.
      • All tags for a given tag stem across a specific facet.
      • All facet names for a given facet name stem.
  • Cache class for long term tag / facet storage.
    • Initally a dummy implementation.
    • IndexedDB datastore, probably using dexie.js as the API to the DB.

A later task will cover advanced features of caches and middleware such as 'sound alike' searches and synonyms.

Initial search UI

The search UI is central to the adventure lookup project. We eventually will want multiple search interfaces depending on user skill and needs. To start with we will create a simple text only search field with no real smarts. This tasks will also be concerned with the display and pagination of results and deal with search refinement.

  • Search interface abstraction (to represent this and future UIs. minimum required for this interface at this time)
  • Basic search field.
  • Connects to search middleware to request data.
    • Coordinate with middleware programmers to determine who will handle rate limiting
  • Basic list of results that updates as user types
    • Pagination of results.

Depends on #4, #5

Advanced search (query builder)

This third search UI is the most involved to create: It will produce an 'advanced search' UI where the user selects fields from dropdowns or sets of available options, and then gets appropriate UI for the value.

It needs to be a composable UI that can perform boolean operations (and, or, not) and grouping. The different fields will have different content types which will require different UIs to provide the data.

This is the most intensive of the search UIs but likely the most powerful for the largest portion of users.

In the context of this ticket the query is the entire search string, a sub query is any particular subsection of that query that could be considered a query in its own right, a facet is an intrinsic or user defined field of an entry, and a constraint is value used to search a particular facet or facets of the data.

  • Add a constraint across any facet (anything that mentions elves)
    • Autocomplete the facet values
  • Add a constraint for a specific facet (setting is Collabris)
    • Autocomplete the facet name
    • Autocomplete the facet value for the given facet name
  • Sub queries that can be joined with a boolean operation:
    • Not some sub query.
    • And all the sub queries.
    • Or any one of the sub queries.
  • Integrate with the middleware. ( #4 )
  • Integrate with the common search UI interface. ( #6 )
  • Optional bonus:
    • Generate a textual equivalent of the query using the infrastructure of the parser UI ( #9 )
    • Generate a query builder value from a parser UI
      • Do it dynamically as the user types.

Depends on #4, #6, #9

Create the application skeleton

Before work can begin in anger we need a skeleton application that can run in the context of the backend teams docker container. This needs to be a minimal build system and set of libraries required to get the a stub application to load in a browser.

  • Infrastructure for development time:
    • Dependency management.
    • Build scripts (get deps, clean, make distribution build)
    • Web server integration with backend teams nginx config.
  • Application stub:
    • Minimal home page controller and view ("hello world")
    • Minimal template
    • Minimal stylesheets
  • Confirm webpack tree-shaking

No Adventure-Lookup application code is required for this skeleton project.

Please try to avoid bringing in 'we might need' dependencies at this stage.

Application Cache and Service Workers

The Application Cache manifest file (Safari/iOS) and Service Workers (Chrome/Android, Firefox) allow applications to run in offline or be installed as 'applications' on a users mobile device. While Service Workers are the future and more flexible, we also need to support the old dog Application Cache for iOS until such a time as Apple decided to support Service Workers.

This task will require some interaction with the build system ( #3 ) in order to programmatically generate the application cache manifest (development without automated manifest management is basically untenable)

I suggest doing the application cache implementation as it is strictly a subset of what the service workers are capable of.

  • Write a build task to generate an application cache manifest.
  • Write a service worker to manage caching relevant assets.
  • Handle graceful reloads when the application updates via either mechanism

Depends on #3

Initial cut of routes and controllers

The UI will need to handle routing and history changes to provide a good UI experience for browser based users. This should be handled by some kind of routing and controller dispatch scheme. This task is to create the basic stubs we know we will need to get off the ground:

  • Homepage / Search page
  • Search page with results: Note this may look like a variant of the homepage
  • Details view page
  • User pages (coordinate with backend team)
    • Log in.
    • Sign up.
    • Account preferences.
    • Sign out
    • Entry add and edit

Depends on #3

Advanced search (parser UI)

In addition to the simple search the project will start with, we also want an 'expert user' text based query builder that is driven by a parser and the autocomplete system provided by the middleware ( #4 ). While this will in practice be the UI for only the most advanced users, its a smaller work load to build and produces the same output, therefore we can start developing and refining the complex query systems sooner.

  • Re-entrant tokenizer. Tokens should supply their start and end position in the stream.
  • Re-entrant parser. Parse nodes should supply their start and end positions in the stream
    • Parser should fail gracefully and attempt to resume. Ignore as little of the users query as possible.
  • Autocomplete popovers.
  • Integrate with Middleware to supply autocomplete information, scoped where possible.

@brehaut recommends investigating a Top Down Operator Precedence based parsing scheme

https://brehaut.net/media/files/al/textbox-metrics/ may be a starting place for the autocomplete popover (its rough as guts though), and https://brehaut.net/media/files/search-proto/ may be a starting place for the parser and tokenizer. Note: Codemirror is just for the prototype, far too heavy weight for our needs.

Depends on #4, #6

Homepage layout

The homepage for adventure lookup will likely be structured around the search facilities. It will also house additional other secondary things. This includes entries into browsing the available entries via editorial content and metadata.

Coordinate with the design team for specifics. Tasks will likely include:

  • Minimal user welcoming content.
  • Integrate search UI (#6).
  • Editorial content such as featured entries.
  • Metadata driven browse entries (by edition/game, by popular monsters, by player level/tier, etc)

Rating

Hi!
I have few questions:

  1. Are there any plans for user rating for adventures?
  2. How can i join development?

iOS web app installation

Users may wish to install the site into their mobile device of choice as an 'app'. To support this we need all assets for all iOS device sizes and metadata configured correctly.

Consult apples latest documentation for details

  • Icons
  • Startup Images*
  • Browser chrome and installation metadata

Work with design team to determine whether we want full screen or browser chrome for installed apps. Do what seems appropriate for iOS separately from Android.

Icons and startup images should be based on site style and Alex Moon's hexagon/magnifying glass icon designs. See documentation wiki for visual style guide.

Depends on #11

Note: some developers have reported bugs in various iOS9 versions where startup images don't display. Still create the assets according to the spec but dig into the veracity of this bug.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.