leftiness / react-demo Goto Github PK

Maybe use thunk. It allows you to send a function as an action to the reducer. The function takes dispatch and the current store state as arguments. It does some things, dispatches some actions, etc... Eventually, it it gets data or finishes its work. You return a promise, so the component which sends the async action can use then() to use the data or ask for more or dispatch more actions or whatever.

Read: https://github.com/gaearon/redux-thunk

If you're an admin or you're the user who created the reservation, then you get to see more information about it like names of guests and stuff. Otherwise, you just get to see that there is a reservation at that time.

• I still want to be able to go to site.com/?sidebar=1 and get an opened sidebar.
• I think maybe I should keep the sidebar open sometimes. If I go from site.com/mail/1 to site.com/mail/2, I want my sidebar to stay open across those two links.
• Therefore, I need to have a combination of URL option and sidebar state on redux.
• If I navigate to a link which has ?sidebar (with any value... but I'll use sidebar=1 in my links) in the URL options, toggle the sidebar to open by setting that state on redux to true.
• When I navigate to a link which doesn't have the ?sidebar option set, it won't close the sidebar. It'll look at what's on the state to determine whether it should be open.

Istanbul?

I wrote some test helpers for the reservations component. result() and spy(). Result should be extracted into a separate file, which itself should probably be tested. Spy... maybe not. I think I should be using a proper spy library, but sinon is being annoying. See issue #50.

Then write tests that expect createElement(element) without required props to throw an exception... and tests that expect foo(x: string) to throw when called with foo(number)... etc.

http://flowtype.org/

You should be able to configure the application to support a certain amount of capacity. If you say that you have five rooms, then you can support up to five reservations at the same time. After that, the time period should be marked as unavailable.

This is wrong. Read below.

I can't look at the props of the connect(Link) to see if it's good. I want to see that I have a link with props: { name: 'test', options: { foo: true } }.

import utils from 'react-addons-test-utils';
import React from 'react';
import expect from 'expect.js';
import { Provider } from 'react-redux';
import { createStore, combineReducers } from 'redux';
import set from 'lodash/set';
import get from 'lodash/get';

import OptionToggleLink from 'containers/OptionToggleLink.jsx';

describe('OptionToggleLink', () => {
  it('should render a Link with a toggled option', () => {
    const renderer = utils.createRenderer();
    const state = {};
    set(state, 'navigation.location.name', 'test');
    set(state, 'navigation.location.options', { foo: false, bar: true });
    const store = createStore((state, action) => { return state });
    const toggle = 'foo';
    const element = React.createElement(
      Provider,
      { store },
      React.createElement(OptionToggleLink, { toggle })
    );
    renderer.render(element);
    const result = renderer.getRenderOutput();
    const atype = get(result, 'type.WrappedType.name');
    expect(atype).to.equal('Link'); 
    // Somehow:
    // expect(link.props.name).to.equal('test');
    // expect(link.props.options.foo).to.equal(true);
    // expect(link.props.options.bar).to.equal(true);
  });
});

react-router is complicated. There's a library to connect it with redux. I'm not convinced that using a bunch of libraries should be necessary to handle something like routing.

Do this instead:

• http://jamesknelson.com/push-state-vs-hash-based-routing-with-react-js/
• http://jamesknelson.com/simple-routing-redux-react/

Container. It'll go into the nav component. Maybe it'll open another container. Like a sign in form in a modal or something.

I could do isomorphic rendering on my react app. Don't do the hot reloading stuff. Overcomplicated. Keep it simple. Like this. Objectively superior:

https://www.smashingmagazine.com/2015/04/react-to-the-future-with-isomorphic-apps/

Sinon doesn't like getting wrapped up with webpack. I don't know why. Maybe I could do something in webpack configuration to make it work, or maybe I could use something else. In the meantime, I'm just going to write a simple spy function. I don't need a lot in order to test the reservations.

Github pages maybe? It's just a front-end after all.

Application component should have an onWidthChange() listener (whatever it's named) which listens to the browser API. The ApplicationContainer passes down the onWidthChange() function. Then the rest of the app will be able to ask redux about the screen size. Split it into small, medium 1000, large 1600. Then they just have to ask for the name of the size. Remember to call the onWidthChange() once after setting it up in componentWillMount so that redux gets that info for its initial state.

I was also thinking that maybe I'd want the sidebar to be open by default if the screen is wide enough. If they toggle it closed, then it'll still get closed.

http://www.sitepoint.com/javascript-media-queries/

Even when the URL after the hash is valid, it goes to 404. Then it doesn't want to follow a link to #/dates because... the hash isn't changing... because it's already #/dates... so the event isn't getting dispatched.

This stuff is not necessarily accurate. I'm figuring it out as I go... More comments over here: #19

onDateChange() will accept the current date (this.props.date) of the reservations component as an argument. When called, this function which is defined on the ReservationsContainer and passed as a prop will retrieve the reservations for the day and then send an action to redux with the new reservations (service.getReservations(date).then((res) => dispatch(setReservations(res)))). onDateChange() should be called once in componentWillMount(). In shouldComponentUpdate(), Reservations component should check the date (this.props.date === nextProps.date). onDateChange() should be called every time that shouldComponentUpdate() lets the reservations component reach the componentWillUpdate() status.

A temporary implementation before I implement the REST service is to just generate a couple of reservations. Maybe I'll stub out the service and return generated data for now so that the ReservationsContainer can be written properly.

The reservations reducer therefore should have a field for the current date, action creators, tests, etc.

This is wrong. Read below.

ApplicationContainer should pass sidebarIsVisible and screenSize props from redux down to Application component. Application component will <SidebarContainer visible={sidebarIsVisible}/> and <componentFromRoutes visible={screenSize !== small} />. If the screen is too small, and they open the sidebar, it'll just show the sidebar. When they close the menu, it'll be a hashchange, so the app will get rendered again, and it'll decide again whether to show just sidebar, sidebar and routeComponent, or just routeComponent.

I'll still need a SidebarContainer for later stuff. It just won't be involved in telling the sidebar whether it should be visible.

There's a console.error complaining about no route for undefined.

I think I might be able to set up one config file with multiple entry points. If you go to site.com/, then you get the "normal" one with the app and everything because it enters at main.js, and you can navigate around the app with site.com/#/foo and all that. If you go to site.com/test/, then you get the tests because it enters at ./test/index.js.

Instead of this:

import Foo from '../../components/Foo.js';

Do this:

import { Foo } from 'components';

I imagined home being like a dashboard. Show the next few upcoming reminders or something. Doesn't seem very good, though. Like it's pointless. Maybe get rid of it if I can't find a good reason to have it.

The form component. The reservation component. Right now, it only has a name field. A reservation component needs date, time, name on reservation, duration, number of guests, phone number, etc

The style is float left so that the rest of the divs will be on the right of it. The problem is that any other elements on the page then feel free to align themselves beneath it. See the new "add reservation" textbox.

I remember using float left because the picnic grid system was being a pain??

(Or container)

I can tell already that the add reservation form is going to be a big thing, and a form in general should have some kind of generic implementation. It'll need validation and stuff, too. It's only going to get bigger.

The reservations container would really benefit from having a stubbed reservations ajax service. It could just generate some foo reservations data and return it with a Promise.resolve(). Then I'd be able to write the reservations container properly.

The sidebar component will need props. Location options site.com/#/home?foo&bar=fizz&sidebar will say whether the sidebar should be visible. Container tells component.

What privileges does the current user have? Not signed in? User? Admin? Show/hide sidebar buttons based on that.

The component should be tested in addition to the reducer.

• https://www.toptal.com/react/how-react-components-make-ui-testing-easy
• https://facebook.github.io/react/docs/test-utils.html

If the place is completely booked for the selected time, you should be able to add your name to a waiting list. Then you'll get a notification, and you'll be first in line for the slot if it opens up. All people on the waiting list will get a notification. All of them will be able to indicate if they want the slot. After a certain amount of time, if at least one person on the waiting list has indicated that they want the slot, then the person who was closest to the front of the line will get it. Everyone else will be notified that they didn't get it. Anybody who doesn't respond or who says they don't want the slot anymore will be removed from the waiting list, and the slot will be marked as having an opening.

I tried figuring it out, but it wasn't working.

https://webpack.github.io/docs/testing.html

https://facebook.github.io/react/docs/component-specs.html#mounting-componentdidmount

http://stackoverflow.com/a/27139507

• React (JSX)
• Redux
• Webpack
• ES6 (babel)
• Mocha

It'll be a container wrapping a normal button. When you click it, fire a redux action to toggle the sidebar. I like Inbox's sidebar. Closed by default.

I'll put it into the nav component.

Eventually it'll work with the sidebar.

rtl = right to left

I figure I can just have the sidebar on the left or right side. Also put the button to open the sidebar on the left or right side with it. Put it in options somewhere.

• See appointments for today.
• Push a button on either side to go to tomorrow or yesterday.
• Add an appointment for the day that you have selected.
• Actions sent to reservations reducer... don't do the REST or anything yet

The current nav works for now because I don't have anything in it really. For example, if I want to show the name of the user who's currently signed in, the nav component will need that information on a prop.

The nav component also needs a prop to say "a user is currently signed in (or not)" so that there can be a sign in / sign out button.

Click a button. Get a modal. Select year, month, day. Modal has an onSubmit. onSubmit takes the values of the modal and sets the URL hash parameters. Application component sends an update because of the hashchange event. Things get rendered. Reservations will be retrieved from the REST API based on the current URL options (site.com/#/reservations?name=Brandon&date=12345).

Pretty self explanatory. Just not sure how it'll work.

Sidebar needs to support clicking tabs at the top (or swiping left right on that tab icon box?) to switch between sidebars. One sidebar would be navigation. Another would allow you to quickly toggle options, and it would link to more detailed stuff like changing your password.