cnpryer / solverstack-web Goto Github PK

After MVP is completed, v1 will need to be optimized to reduce strain on the client. Some inputs don't need to trigger any state-based behaviors.

test users will only be using the Route module initially. until this is polished and improved sufficiently I'll either fully block off or put placeholders in for the following pages/features:

• Login
• Registration
• Trending (has placeholder)
• Create (has placeholder)
• Discover
  • Chained (disable)
  • Geocode (disable)
  • Depot (disable)
• Geocode Setup
• Depot Setup

Include any information about why these are blocked off and when we plan to release them/how (maybe add to home page).

see dependabot alert

the visual sometimes will render offset in a position not centered within each card. i have not narrowed down the true root cause, but this is probably due to the current implementation of the initial draw. we'll handle this for v1.

From my understanding (could be out-dated or even incorrect), google maps api is pretty pricey for large-scale integrations. Since we really don't need direction-level routing visualized or even returned to the user, we should start with just creating our own simplified and clean visualization of the vrp stack's outputs. We can do this using d3.js.

After minimum features of the main crud service is completed, the client needs to be baked with user-based module chaining. This is where data from one module can be chained into another module.

Example: Geocode -> Depot -> Route

polish out the alert for column requirement parsing on the input files

setState does not update state of variable until scope is returned. isAnimation will be used to stop and start and animations.

whenever a user passes a zipcode+country that does not geocode the geocode service will return NaN values, but for the MVP we're returning 0s to simplify. To accommodate we'll scrub out null island geocodes after the response and notify through a basic alert.

Maybe include a "?" users can hover over for input file requirements.

1. Must be tidy .csv
2. Must contain exact columns "longitude", "latitude", "pallets".

hardcoded cards of Featured Stack (demo stack), Geocode, Depot, Route.

Add a green button to bottom left of card to download result data.

I opened up a file a user submitted to the Route module in notepad. At the bottom there was a trailing row that threw the isMarkerContiguousUSA check (undefined, undefined).

Add parsing in to check for this and if it exists remove.

raw events would be used to build tooltips in d3.

generic landing page (no SEO). SEO is pushed to v1.

General
Users should sign up with the intention on finding a module to use in order to solve their simpler problems.

Home page should preview featured stacks, users, and daily modules news (what are new components released into the ecosystem).

Each stack should orchestrate very clear data oriented flow to problem solutions. One example is the requirement of a basic routing model.

“Routing” searches should show basic routing solverstack available for mvp. This stack may include modules/components such as:

• Location Data Processing

  • Node Indexing

  • Geocodes and Previews

  • Distance Matrices

• Model Assumption Helpers

  • Have weight; no pallets

  • Have pallets; no weight

• Ortools RPC Head

  • Constant Vehicles

  • Constant Capacities

  • Ortools Basic Capacitated Solve

  • Open Sourced RPC API Flask Service

• Ortools VRP Dashboard

  • Intractable Visual Prototype

  • Stand-alone Add-on Prototype (Just redirect from Head)

• Genetic Algorithm Ortools Scheduler

  • Constant Driver Count

  • Required USA Driver Regulations Adherence

  • Rust or NumPy Service

  • Gantt

NOTE: some design battles will be how to blend redundancy in UI. Example: Ortools Head is current vrp setup box. Geocoding previews can overlap with this module head. What should occur is a natural prioritization of ortools over geocoding. Maybe assign weights to modules within stack (representing order) and propagating hide vs show down it. This also ties into the peer-review-like nature of the ecosystem - where people influence stacks for iterative publishing. This can be done as a PR type process but more granular. Think discord chats but adjacent to the life of a stack. Conversation/peer review requests can be toggled into view.

Users should be able to search for a module, see it in their feed (on a stack studio page) click to add/append to stack. You can create stacks with one module or 100 as long as each are configurable. All configuration should be defined by data objects and targets.

Solverstack ecosystem can allow devs to integrate with apis and sdks. We can create solverstack object validation at integrated endpoints. If custom modules want to be contributed we can offer methods involving basic github linking for smart modules, full blown service integration, or in-app solver-lang module construction.

I'm new to node, but if it's anything similar to virtual environments in python, I'd like to slim down the dependencies we have here. There seems to be a lot.

After optimized routes are returned from the service we'll update the map with connected nodes in accordance with their route assignments.

Right now everything was brute-forced. This is not sustainable and ignores react-friendly designs. By refactoring we'll enable better component re-usability and improve general performance.

right now we are just ordering the route sequence in the d3 visual as it is ordered in the original input data. we are already capturing the stop sequence number so all we need to do is just instantiate a list of a route's size and then insert the correct stop into that list (all within the current createRoutes function.

For the mvp we'll have a demo implementation of chained stacks (geocode, depot, route). This will be the "featured stack" for early versions.

bake in jwt for persistent user sessions and service integrations.

urls /setup/* should be /stacks/*

/setup/vrp has a map with some inputs for an origin and destination nodes. the map is limited to USA and uses d3 to draw the elements on/as react components.

On load the svg is drawn and has responsive resizing from that point on. After a resize, however, the plotting functionality remains aligned with the original expected size of the default svg draw.

for the mvp we'll implement a generic loading visual instead of custom d3.js animations. The d3.js animations will be pushed to v1.

the contiguous USA requirement is too strict at the moment, alerting users when there aren't international destinations (need to debug).