opentripplanner / otp-ui

React component library, which can be used to build trip planner webapps.

OTP-UI React Component Library

Description

React component library, which can be used to build trip planner webapps.

See:

• Examples and docs (via Storybook)
• Current npm releases
• A reference implementation of otp-ui -- IMPORTANT NOTE: otp-ui use in otp-rr is a WIP / TBD

Getting Started

 git checkout https://github.com/opentripplanner/otp-ui.git
 yarn dev # (installs packages, transpiles files, opens storybook to running component library on localhost:5555)

Development

You can chat with the main OTP-RR developers in our Gitter chat. Support is not guaranteed, but we may be able to answer questions and assist people wishing to make contributions.

Some packages in otp-ui depend on sibling packages (e.g., @opentripplanner/core-utils is used by many of its siblings). In order to test a package with local changes you have made to its sibling, you can run the following find/replace operations to make sure you're depending on your latest work (and not the released version):

1. In the package.json files for packages in which you want to test the sibling, find and replace (package-to-test being the package with local changes -- make sure these are committed to first to avoid the find/replace operations below polluting your work):

   "@opentripplanner/package-to-test": "current-version"

   with

   "@opentripplanner/package-to-test": "file:../package-to-test"

2. Run: yarn && yarn dev

If the Storybook addon bar (a bar of controls at the bottom of the story) does not appear, you may need to clear localStorage by opening the browser console and typing localStorage.clear().

Storyshot testing

This repo utilizes the Storyshot Storybook addon to perform snapshot tests of every story in this monorepo. Whenever the script yarn unit is ran, the Storyshot addon will be included along with all the other tests. It will compare the initial output of every story to the saved snapshot of that story. This provides a quick way to make sure nothing drastic has changed and that every single story is able to initially render without an error. Storyshot doesn't snapshot all possible changes that can be done while interacting with story components. Often times these snapshots will need to be updated and that can be accomplished by running yarn unit -u.

Stack

A Monorepo with multiple packages and a shared build, test, and release process.

• 🐉 Lerna  - The Monorepo manager
• 📦 Yarn Workspaces  -  Sane multi-package management
• 🚀 React  -  JavaScript library for user interfaces
• 💅 styled-components  -  CSS in JS elegance
• 🛠 Babel  -  Compiles next-gen JavaScript
• 📖 Storybook - UI Component Environment
• 🃏 Jest  -  Unit/Snapshot Testing

Usage

• yarn dev - This starts Storybook for viewing all the components locally.
• yarn bootstrap - This installs all of the packages and links dependent packages together.
• yarn preppublish - This babelfies all of the packages and creates /lib folders for each one.
• yarn unit - Run jest unit tests.
• yarn coverage - Shows jest unit coverage.
• npx lerna changed - Show which packages have changed.
• npx lerna diff - Show specifically what files have cause the packages to change.
• npx lerna create <packageName> - Creates new package and walks through setting up package.json

Releasing

This project uses semantic-release to create releases to NPM. It is expect that contributors create Conventional Commit messages. These are then parsed by semantic-release which will automatically create an appropriate release for each package whenever a branch is merged to master.

Sometimes when creating new releases, it will be necessary to update numerous packages within this repo at once to a newer internal package version. For this purpose there is the update-internal-dependencies script. This should be ran manually as needed. By default, yarn update-internal-dependencies will update all dependencies with the @opentripplanner scope in all packages within this project. To only update specific dependencies, it is possible to run something like yarn update-internal-dependencies core-utils base-map. This would update all dependencies on either the @opentripplanner/base-map or the @opentripplanner/core-utils in all packages in this project.

Raster Tile Versions

As of Fall 2022, the otp-ui map layers have migrated from Leaflet to MapLibreGL. This migration was a breaking change, so existing uses of otp-ui should be unaffected. If you wish to migrate to the latest version, please see the Migration Guide.

We understand not all will want to upgrade to vector tiles right away, and so will be maintaining the raster tile versions of all relevant packages for the foreseeable future.

The following table lists the last major version of each package which uses raster tiles. These major versions will receive fresh minor versions as updates are needed.

Package	Latest Major Version with Raster Tiles
base-map	2
core-utils	7
endpoints-overlay	1
itinerary-body	4
park-and-ride-overlay	1
route-viewer-overlay	1
stop-viewer-overlay	1
stops-overlay	4
transit-vehicle-overlay	2
transitive-overlay	2
trip-viewer-overlay	1
types	3
vehicle-rental-overlay	1
zoom-based-markers	1

Internationalization

OTP-UI uses react-intl from the formatjs library for internationalization. Both react-intl and formatjs take advantage of native internationalization features provided by web browsers.

Language-specific content is located in YML files under the i18n folder of packages that have internationalizable content (e.g. en-US.yml for American English, fr.yml for generic French, etc.).

Note: Do not add comments to these YML files! Comments are removed by yaml-sort during pre-commit. Instead, comments for other developers should be placed in the corresponding js/jsx/ts/tsx file. Comments for translators should be entered into Weblate (see Contributing Translations)

To use the YML files in your react-intl application:

• Merge the content of this file into the messages object that has your other localized strings,
• Flatten the ids, i.e. convert a structure such as

    otpUi > ItineraryBody > travelByMode > bike
  

  into

    otpUi.ItineraryBody.travelByMode.bike
  

• Pass the resulting object to the messages prop of IntlProvider. See packages/from-to-location-picker/src/index.story.tsx for an example of how to initialize localized messages with IntlProvider.

Using internationalized content in the code

Access the internationalized content in code, typically using either

import { FormattedMessage } from "react-intl";
...
<FormattedMessage id="..." />

or, if you need a string,

// Obtain `intl` using `injectIntl` or `useIntl`.
intl.formatMessage({ id: ... })

where the id passed to FormattedMessage and intl.formatMessage can be literal or a computed value. See Internationalization checks and reporting for caveats.

Internationalization checks and reporting

Code and translation integrity is checked by scripts that you can run locally. check:i18n-all checks for all languages. check:i18n-en-fr checks for English (US) and French and is run on GitHub after each push.

These scripts check the following:

• All entries in the applicable translation files are used in the code.
• All message ids used in the code have translations.

For the scripts to work best, you should use literal ids as much as possible with <FormattedMessage> or intl.formatMessage. This is because the scripts use the formatJS CLI, and the formatJS CLI simply ignores message ids that are not literals.

Exceptions to checks

Exceptions to the checks above can be defined when:

• Reusing a message defined in another package,
• A message id needs to be computed, with some portion of it coming from a parameter, and implementing a switch case does not provide substantial benefits.

Exceptions are defined in optional files named i18n-exceptions.json. See the scripts package README for setting these files up.

Contributing translations

OTP-UI now uses Hosted Weblate to manage translations!

Translation status for OTP-react-redux and OTP-UI on Hosted Weblate

Translations from the community are welcome and very much appreciated, please see instructions at https://hosted.weblate.org/projects/otp-react-redux/. Community input from Weblate will appear as pull requests with changes to files in the applicable i18n folders for our review. (Contributions may be edited or rejected to remain in line with long-term project goals.)

If changes to a specific language file is needed but not enabled in Weblate, please open an issue or a pull request with the changes needed.

otp-ui's Issues

Remove inline `<b>` markup

Inline <b>, <i>, <u> markup should be converted to <span className="..."> tags with css styling, or to styled elements.
Refs: #38, #60, #7

location field: override icons (possibly using Slots pattern)

Our components will eventually need to allow the caller to override icons and other styling.

stop search: location field and geocoder components

We're going to (eventually) need a few changes to the location field to handle stop searches.

I have to validate a lot of the following functionality, but I'm fairly certain we're going to need a few changes in order to deal with stop searches. If you look at the current trimet.org, the geocoder form does two unique things:

1. the geo searching is restricted to searching for just a stops layer (and not addresses, landmarks, etc...). In the Pelias world, this means sending down the 'sources' parameter, ala https://ws-st.trimet.org/pelias/v1/search?text=zoo&layers=stops
2. from the response, we're going to need access to the stop id (and agency id). Pelias (via the transit loader) accomplishes this by encoding stop and agency ids in record id, ala id": "10299::TRIMET::stops", Clients of the geocoder / location field components will need to access those ids, in order to make follow up calls to other data services (e.g., like transit tracker arrival information)

Add ability to filter layers from geocoder result sets in LocationFieldComponent

@fpurcell has recently added the ability to get routes to be searchable from within the PELIAS geocoder and is very useful in general cases, but in some contexts we want to be able to prevent that "layer" from being a part of the search results. An example where this can cause buggy/unwanted behavior is when planning a trip. A user may unintentionally plan a trip using a "route" layer item and the trip planner will plan a confusing trip based on that.

We were thinking it would be good to have a generic way to pass the "layers" we want to filter out before being presented in the locationField results. We are open to talking more about this feature, but ultimately think it is necessary in order to fulfill our requirements on the trimet.org site

itineraryToTransitive utility throws an error if the OTP response lacks intermediate stops

Randolph reports that the itineraryToTransitive utility throws an error on an itinerary response lacking intermediate stops (e.g., have to call OTP with showIntermediateStops=true, else no intermediate stops == broken rendering.

Related to #21

Itinerary Components Feedback from AltSource

We primarily have styling feedback for items that we cant override using Styled-Components. There is stuff that is related to component ordering and actual content within the components.
Most of the requests are also related to getting the view to look more like the UI mocks the Trimet marketing team provided for us. Let me know if you have any questions or comments, thanks.

OTP UI Feedback:

• Change verbage on Transit Legs to have "Board" verb in it (Old: 52 Farmington/185th to Beaverton TC) (NEW: Board 52-Farmington/185th to Beaverton TC)
• Internals of "LegClickable" under the transit component causes centered multi-line styling.
• Allow for real-time arrival information to be passed into the itinerary body/Trip Legs.
• Change Trip Viewer Details info from "Ride 10 min / 15 stops" to "10-minute ride (15 stops)".
• Drop the "Service operated by Trimet" section on a transit leg. Or make it optional via a prop/config
• Add the service alerts section below the Trip viewer details section on a leg, instead of being on top.
• If The Service Alert section only has 1 alert, show it by default with a brief one-line display of the error.
• Some PropTypes could get some improvements. It was difficult to know what all the functions did and what they should take without diving into the actual library code.
• Is there a Handler for the "View leg on Map"/Map button on the right-side of the trip leg?

PERFORMANCE: Optimize moment.js

Look to reduce the data footprint of moment.js.

See #65

`fareType.details` entries should be of type `arrayOf({ fareId, price, routes })`

The fareType type definition is not consistent with data returned by OTP and causes browser errors log inside the TripDetails and PrintableItinerary components. The errors read as follows:

OTP returns the following structure for fares:

For reference, the current definition of fareType is, per
https://github.com/opentripplanner/otp-ui/blob/master/packages/core-utils/src/types.js#L267:

export const fareType = PropTypes.shape({
  details: PropTypes.objectOf(
    PropTypes.shape({
      fareId: feedScopedIdType.isRequired,
      price: moneyType.isRequired,
      routes: PropTypes.arrayOf(feedScopedIdType).isRequired
    }).isRequired
   ...

Prop casing for transit-vehicles-overlay, itinerary

React props should be camelCased, however there are instance of PascalCased and alllowercased props in itinerary and transit-vehicles-overlay. This issue is to see whether/how to address them.

trip-form: SettingsSelectorPanel should allow custom icons

This is an issue for implementers who wish to use a custom icon set that is not tied to OTP-UI's icons package.

base-map: map extent / offset based on left nav bar

Zooming the map to the extent to a trip plan will be an interesting endeavor (at least to me) on the new trimet.org, due to the left nav bar.

Without adjusting for the hovering left nav, we get results similar to what happens currently on the call app when a trip is first planned, where the trip geometry is hidden under the left nav:

The desired extent would look something more like this:

e.g., zoom to a smaller / right-shifted map extent...

New props for TransitVehicleOverlay component

We will need a way to capture click events from the TransitVehicleOverlay component. When a user clicks a vehicle we will want to be able to invoke certain behavior in the app that is implementing the component.

In order to get that done we will need something like an onVehicleSelected callback At the very least we will want the vehicle id supplied as an argument but we could also work with the full vehicle object. It's unclear if we will need access to the actual event from leaflet but at the moment it looks like that's not necessary.

We're wide open the details of the interface, naming, etc here so additional suggestions are welcome.

Additionally when framing the selected vehicle in leaflet we will need to pass in an options object that handles the paddingTopLeft and paddingBottomRight properties seen here https://leafletjs.com/reference-1.6.0.html#fitbounds-options

In our app we're dynamically setting these properties for account a sidebar that is overlaid on the map when used on a desktop. Recentering of the map should account for this.

Thanks.

Remove componentWillRecieveProps from __mocks__ story class

otp-ui/packages/base-map/__mocks__/SelectVehicles.js

Line 79 in 8bfcd39

componentWillReceiveProps(/* nextProps */) {}

Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.

• Move data fetching code or side effects to componentDidUpdate.
• If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
• Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder.

Please update the following components: SelectVehicles

Allow custom icons for EndpointsOverlay component

In order to match our mocks, we'll need to customize the icons used in the EndpointsOverlay component. The way we supply custom icons to the LocationField component seems to work well. I'm good with following the same pattern if it can be used. If there is an existing prop that already allows me to do that then just let me know. Thanks a lot.

Long press functionality in BaseMap component

We have a request on the TORA project to implement long-press functionality in the app. The user will be using this for specifying a current location manually from the map instead of using geolocation API. onMapLongPress prop added to basemap (or something equivalent, the name can be up to you).

Alternately if you wanted to provide more granularity to the 'onMapClick' callback argument then we can handle things that way. We noticed that it passed an event name of singleclick so we can look at that event to switch behavior. This would keep your prop list a little shorter if you want.

Reach out if you have any questions or need any clarification. Thanks as always.

Rename `transitOperatorType.logo` to `transitOperatorType.logoUrl`, make it optional

Prop transitOperatorType.logo defined at https://github.com/opentripplanner/otp-ui/blob/master/packages/core-utils/src/types.js#L43 should be renamed to transitOperatorType.logoUrl so it is obvious that the implementer has to provide a URL. Also, it should be optional because of the fallback to the agency branding logo at: https://github.com/opentripplanner/otp-ui/blob/master/packages/itinerary-body/src/TransitLegBody/index.js#L114. By making it optional, for the case of a single agency, implementers do not have to repeat the transit icon URL.

URL utils: add utils from otp-rr for calling OTP and/or pulling up app state

From this Slack conversation: https://trimet-mod-sandbox.slack.com/archives/CRC48NTJ4/p1579567951000400

There definitely is more nuance to constructing the query params. That logic is contained within here: https://github.com/opentripplanner/otp-react-redux/blob/906d9226553cbbdd83cf455986f199c5a6964f72/lib/actions/api.js#L164-L246

I could move this method over to @opentripplanner/core-utils/src/query if that would be helpful.

---

Randolph: ... Would be great to get a util that does the opposite (query object to OTP-API string) put in the OTP-UI. I did try and extract the logic from that api module and it got kind of tricky. We would use that module at least twice. Once when talking with the OTP API and another when generating the query params string for trimet.org urls when we need one. If you need anymore details, just let me know. Thanks.

evansiroky
ok ... Can you create a github issue please?

PERFORMANCE: import statements, ../lib/... paths and tree-shaking

A note about using .../lib/... paths on import statements:

In a future PR, I'm going to go thru all the files in otp-ui and switch all the .../lib/... import paths to .../src/... Cole pointed out that by us using transpiled .../lib/... code, we're preventing webpack from tree-shaking the otp-ui code (at a latter date / latter production build of an app), resulting in larger footprints than might be necessary (could be a big deal, esp if all the icons from the otp-ui Icons component are repeatedly pulled into everything we do -- esp. when we might only intend to use one or a small handful of those icons). We might do more, based on Cole's continued research in making the code performant.

IMPORTANT -- this is desired:

import utils from "@opentripplanner/core-utils";
center: utils.types.latlngType.isRequired,

was:
import { latlngType } from "@opentripplanner/core-utils/src/types";
center: latlngType.isRequired,

base-map: change overlay layer's 'visible' prop when controlled via the layer switcher

In otp-rr, the base-map's layer control updates the value of the 'visible' prop on added base layers. Conversely, the otp-ui base-map component doesn't change said child components' 'visible' prop value from what was originally specified. Would like otp-ui to mirror what otp-rr's layer switcher code does, and update the value of visible to either true/false, to thus reflect the state of the layer switcher for said layer.

This is important because the 'visible' prop, beyond setting the original state of which layers might be hidden / visible on app startup, is more importantly used used to turn on/off interval code and data updates. With so many dynamic layers (e.g., e-scooters, bikes, rt vehicles), we only want the client doing fetch() work and updating leaflet layers when the layer is visible.

See these layers for use of visible to control the setInterval/clearInterval code:

• https://github.com/opentripplanner/otp-react-redux/blob/dev/lib/components/map/zipcar-overlay.js#L44
• https://github.com/opentripplanner/otp-react-redux/blob/dev/lib/components/map/vehicle-rental-overlay.js#L46

Slot for Custom Popup on Vehicle Layer

We would like to have a prop/slot for a custom popup on the vehicle layer.

As it stands, we will only need to display one of these at a time. See the example of how we would use it to display the Vehicle time. It would follow the tracked vehicle.

For this, I think that the slot pattern might serve us best where we can pass in a particular implementation. Inside of the implementation, we could have the component

<Vehicles
    ...
    customVehiclePopup={<MyCustomVehiclePopup/>}
    ...
/>

At a glance, we may be able to use a popup element for this but I am open on the implementation. We may try a couple of different approaches to see what works here, we haven't experimented with passing a stateful component into a popup yet but I think we can find a way to make something work.

Alternately we can always pass in some static markup. I will run some experiments on Monday to see.

Util to convert OTP Modes into human readable label

Currently the OTP Settings Panel has the ability to convert modes from the config into buttons with human readable labels, It would be great to be able to utilize that logic as a utility function for other places in the application as well.

inputting MICROMOBILITY_RENT into the function will return Transit + E-Scooter
inputting BICYCLE will return Bike Only when no transit options are chosen. Will return Transit + Bike when transit options are chosen.

If there are only transitModes in the selected List, return Transit

I attempted to build a somewhat working version of this but it doesnt handle all edges very well

const convertToObject = (newObj, mode) => {
  // eslint-disable-next-line no-param-reassign
  newObj[mode.mode] = mode;
  return newObj;
};

const getModeLabelFromConfig = (modes, modeString) => {
  const flatConfig = {
    ...modes.accessModes.reduce(convertToObject, {}),
    ...modes.exclusiveModes.reduce(convertToObject, {})
  };

  return modeString
    .split(',')
    .filter(
      m => !modes.transitModes.map(tm => tm.mode).includes(m) && m !== 'TRANSIT'
    )
    .map(mode => flatConfig[mode].label)
    .join(' + ');
};

location field: more control over the component

• need to toggle "Use Current Location" (display, etc...)
  

  • only 1 callback per location
  • collection of favorites
    

Storybook: look to switch from addon-info to addon-docs

storybookjs/storybook#6833 (comment)
and
https://medium.com/storybookjs/storybook-docspage-e185bc3622bf

Custom Icon prop for Vehicles Layer

We would like to have a custom icon prop for the vehicles layer. This would be an icon that we can use to mark a vehicle on our overlay and would allow us to replace the icon that's currently being used to represent a vehicle. This is a lower priority than some of the other Vehicle layer requests.

We've managed to implement the custom icon for StopsOverlay. I think something similar could work here as well but we are open to ideas on this.

NaN bug with `query/planParamsToQuery` util

We found a bug with the planParamsToQuery function inside of v0.0.12 of core-utils

otp-ui/packages/core-utils/src/query.js

Line 213 in c6e6225

if (!Number.isNaN(params[key])) query[key] = parseFloat(params[key]);

Strings passed to the default case in this function are being turned into NaN. Having compared this to the OTP-RR code it looks like the global isNan was swapped with Number.isNaN when being added to OTP-UI's core utils. Number.isNaN will not implicitly coerse strings.

Worth noting that empty string values passed to the default condition still return NaN even with the global version of isNaN being used. We should be able to gracefully handle this condition in url query params

There are a couple of ways to address this. Feel free to reach out if you need some ideas or guidance. I think the best solution here will be to coerce the value with to a number before checking it with Number.isNaN

If this is the way it's intended to work then we can double-check this after the utility that constructs the OTP routing params has been released.

Thanks!

Description, getting started and demo deployment missing

These would be useful additions

PEFORMANCE: transit-vehicles-overlay and leaflet zoom & panTo

See #67

binh-dam-ibigroup: Is there a way for the overlays to not control the map?
setMapZoom = throttle(500, zoom => {
this.setState({ mapZoom: zoom });
this.recenterMap();
});

TODO: understand why zoom and pan events don't just update the vehicles layer, as opposed to placing the zoom level in a state variable, etc.... End result will hopefully find a way to simplify the zoom (state) and panTo calls in RT Vehicles.

Why does map zooming and panTo (i.e., recenterMap()) not just work, and why do I seemingly need a state variable for zoom level for my layer to recognize viewport / zoom / pan events? Why do calls to leaflet.map.panTo not just move the map -- why do I also need to update data for panTo to move the map?

Note: the workarounds now are to track the map's zoom level in a state variable, which then triggers a React redraw of the vehicle marker layer. There's got to be a better / simpler way to have the layer redraw different icons based on zoom level.

trip-form: ModeButton button should use native active prop.

The button element in the ModeButton component defines its own active/disabled CSS class, it should use the native HTML and CSS state instead.

Example: At https://github.com/opentripplanner/otp-ui/blob/master/packages/trip-form/src/styled.js#L100

    &.active {

should be instead:

    &:active {

From-To-Picker is being imported incorrectly into StopsOverlay

When attempting to use the StopsOverlay package inside of the new trimet.org site, we ran into a webpack build error, that we believe is a symptom of a bigger issue:

ERROR #98123  WEBPACK
Generating development JavaScript bundle failed
Unexpected token (11:14)
File: node_modules\@opentripplanner\from-to-location-picker\src\index.js:11:14

The contents of that file (and otp-ui in general) look to be utilizing "@babel/plugin-proposal-class-properties": "^7.7.4",. The class properties in FromToLocationPicker havent been transpiled into valid JS within the library, so our webpack build fails.

After digging deeper into this, to find a solution, we believe the offending line of code is within packages that contain a module:

 "main": "lib/index.js",
  "module": "src/index.js",

We found an SO issue discussing the module item makes es6 module imports to use the specified file instead of the minified lib code: https://stackoverflow.com/a/47537198/4625508. We arent fully sure if this is the cause/root of the webpack issue, But we think its a solid starting point for continuing to investigate the underlying issue.

Transitive Overlay rendering is inaccurate without intermediate stops

When rendering an itinerary without intermediate stops, the transitive overlay looks to be inaccurate. It looks like it only renders the geometry between the last two stops on each leg.

With intermediate stops:

Without:

location field: expose record type and id from geocode response in the onLayerSelected callback

See #13

Would like calling app to have access to data from the geocoder beyond name and coordinate. In Pelias there are 2 properties that carry needed information. The 'layers' property describes what type of record (e.g., a stop vs. an address vs. a venue, etc..). The 'id' property, for certain records, contains valuable information, like stop_id and agency_id (for layers=stops). Eventually there will be a 'routes' layer, which will contain a route_id, etc... The use of those 2 properties (type and id) might work well, since all records in Pelias have those fields, plus guessing other geocoders have similar values (e.g., should make things universal). That said, open to suggestions on other solutions and ideas to communicate needed information back to the calling app.

Trip Details: trip itinerary footer explaining when and how much an itinerary will cost

Query prop validation errors in OTP-RR

It looks like the queryType we defined in the core-utils package and used in the SettingsSelectorPanel has type information that is not consistent with the query data that is passed from OTP-RR.

Affected fields: (they are not used inside SettingsSelectorPanel)

• queryType.from
• queryType.to

Validation error:

• Expected: String
• Actual: {name: String, lat: Number, lon: Number}

itinerary-body: time and route dot (styling issues)

In the itinerary-body component, two styling issues jump out.

a) optional filter of long route names showing up in the dot:

For MAX and Streetcar routes, there's a truncated text in the route 'circle'. Would like an component prop option to limit the size of text going into that circle (e.g., maybe a number, representing the max number of characters of the route name for it to render in the circle ... so our maxRouteNameLen <= 3) and thus filter the MA that's currently showing up:

(Would rather just a red dot, than the partial string, and thus the MA above)

b) time alignment issues:

Both the vertical and horizontal alignment seen in the MOD app is also desired from the OTP-UI components.

Current alignment has a larger gutter to the right of the time on the horizontal, and the vertical is also a bit off (as seen in both the Storybook image above, and the top image from the new trimet.org app)

See #94 for other related itinerary-body changes.

Storybook: warnings and console.log dump

Getting this warning from Storybook:
@storybook/source-loader was applied to a file which does not contain a story. Please check your webpack configuration and make sure to apply @storybook/source-loader only to files containg stories.

Affected Stories:

• http://www.opentripplanner.org/otp-ui/?path=/story/settingsselectorpanel--settings-selector-panel-styled
• http://www.opentripplanner.org/otp-ui/?path=/story/datetimeselector--date-time-selector-styled
• http://www.opentripplanner.org/otp-ui/?path=/story/trip-form-components--check-box-selector-styled
• http://www.opentripplanner.org/otp-ui/?path=/story/trip-form-components--dropdown-selector-styled
• http://www.opentripplanner.org/otp-ui/?path=/story/trip-form-components--general-settings-panel-styled
• http://www.opentripplanner.org/otp-ui/?path=/story/trip-form-components--mode-button-styled
• http://www.opentripplanner.org/otp-ui/?path=/story/trip-form-components--mode-selector-styled
• http://www.opentripplanner.org/otp-ui/?path=/story/trip-form-components--submode-selector-styled

EndPointsOverlay: Replace `MapMarkerIcon` into `fromMarkerIcon` and `toMarkerIcon`

I think the way the <EndpointsOverlay> tag reads is inconsistent in the sense that
it defines two distinct fromLocation and toLocation, so you would imagine there is a separate icon prop for the from and to locations. In reality, the component defines a single MapMarkerIcon that represents two separate icons (or more, if the location prop is used). My suggestion would be to split MapMarkerIcon into a fromMarkerIcon and a separate toMarkerIcon. For each of these icons, the implementer can have separate logic to draw different icons based on location for instance.

Make StopMarker Component APIs consistent on StopsOverlay and StopViewerOverlay

Small nitpick but the the StopsOverlay StopMarker expects a prop named stop while the StopViewerOverlay expects a StopMarker component with a prop named stopData. Would be good if these were consistent across both. For reference on where the differences are:
stops-overlay/src/index.js:line69
stop-viewer-overlay/src/index.js:line40

location field: styling improvements

• easier to extend styling if className prop is passed down to root element
  

the link in the image above is: https://www.styled-components.com/docs/basics#styling-any-component

• export distinct className ... help overcome hacks needed to control nested elements
  

• menu items in location field ... possible not to have menu display stuff?
  

• aria-label supplied by user of component
  

Improve transit-vehicle-overlay

Related to #52

From Evan's PR #51 review:

SettingsSelectorPanel: should not keep query params in its internal state.

Doing this is causing the component to not respond or render correctly to new props (e.g. those set in OTP-react-redux by the redux store).

In the development screenshot below, both panels should show the same selections after clicking on the lower panel, but the streetcar selection states are not the same.

New Props for Stop Viewer Overlay

Lots of similarities between this and issue #59:
We will need to be able to support custom icons for a stop Icon marker.

Currently there is no way to prevent the popup when clicking on a stop. We would like an optional prop to hide pop-ups on the overlay.

Trip Form Settings Selector Panel feedback

Hey All, just wanted to get these in front of you asap, so that they can get acknowledged when possible. Please Let me know if you need help reproducing any of the issues. Thanks!

Travel Preferences settings (ie "Optimize For/Walk Speed/Maximum Walk") with any mode of traveling is not functional. Receiving uncaught TypeError. This is visible in the OTP UI Storybook.

Trip Form/util.js line 156 is rendering an IconTag by doing a direct key lookup on line 148 which can come back null silently if the key doesnt exist.
The rendering will fail when a user tries to render that company Icon when the relevant mode is selected.
We hit this issue when one our companies had all caps as the ID instead of the normal casing.

micromobilityModes array is req'd in the supportedModes prop even though Trimet doesnt support Micromobility only modes of traveling. Without it, getBicycleOrMicromobilityModeOptions throws a `TypeError: cannot read property 'map' of null

Pass the leg index into frameLeg callback

We have done the necessary integration work to frame a trip leg within the trip tools map when the associated "map" icon button is clicked next to the associated leg. We are blocked from completing this work though because the frameLeg callback does not include the leg index when invoked inside of the OTP ItineraryBody component (to be more specific it's called inside of PlaceRow) I think this should be a simple matter of wrapping the onClick handler with an arrow function and supplying the legIndex as an argument to frameLeg however, we're open to any other things you may want to do (i.e. passing the entire leg if you think it meets your own needs).

At the very least, we need some reference to the leg that's just been clicked by the user. If I can offer up any more detail or clarification then please let me know. I think this should be fairly straightforward.

@fpurcell since we are so close to wrapping this feature, what are the changes of us getting this request expedited? I think this can be wrapped with a very small update. Let me know. Thanks.

Failing PropType `leg.hailedCar` failing in PlaceRow

Was receiving this failing propType and traced it down into OTP UI. The leg service has booleans for the property leg.hailedCar, which you can verify by looking at the mock data.

Failed prop type: Invalid prop leg.hailedCar of type boolean supplied to TriMetLegIcon, expected string.
in TriMetLegIcon (created by PlaceRow)
in PlaceRow (created by ItineraryBody)

location field: more data returned from geocoder

AltSource's comments:

Frank's $0.02 (see SEE #9 for more...):
We're going to need a geosearch form to only search on the 'stops' layers in Pelias.
https://ws-st.trimet.org/pelias/v1/search?text=6&layers=stops

We're also going to need that form to return the stop_id and agency_id fields, which are encoded in the response via the id field -- e.g., {stop_id}:{agency_id}:{layer_name} is how the id field is composed in Pelias for transit (stops from GTFS).

SEE #9 for more...

Print Itinerary: add new component to itinerary related components

Have alternate trip itin rendering for print.

New Props for StopsOverlay Component

Based on requirements for the new trimet.org project, we will need to be able to support custom icons for stops. There are multiple styles such as a fully colored version, an opaque version, etc.. We think the best way to get this behavior is to provide a prop that lets us inject the marker object.

Currently there is no way to prevent the popup when clicking on a stop. We would like an optional prop to hide pop-ups on the overlay.

Currently there is no onClickHandler for the markIcon itself. We need this in order to tie into other functionality within the trimet app, and we would expect the stopId would be propogated up.

Redundant ModeIcon class

Is this duplicative of https://github.com/opentripplanner/otp-ui/blob/master/packages/icons/src/trimet-mode-icon.js? I suppose that's ok if so, but we may want to create an issue for this repo identifying potential spots for refactoring. This could get messy if we have a bunch of the same code repeated in different packages.

Originally posted by @landonreed in #20

componentWillReceiveProps -> componentDidUpdate

base-map componentWillReceiveProps (deprecated) in mock code:
packages/base-map/mocks/SelectVehicles.js

TRIP PLANNER FORM: bike mode and options

The FLATTEST and QUICKEST trip options, when combined with a bike mode option, are generating some unsafe trips (e.g., Ross Island Bridge specials).

So the desire right now (at least until we get a bike triangle again, etc...) is where a bike mode is used, not give the option drop down. Just go with SAFEST bike mode option. That said, if we combine bike and transit, and can apply SAFEST to bike, and then give the FEWEST TRANSFERS and QUICKEST options relating just to the transit modes, that would be fine.