Learning Preferences App

README.md

I'm looking for your help to help me understand React better.

I have an idea for a simple app. It’s based on an educational activity I did in a training session once, and I think it’s a good opportunity for me to learn React.

Here’s the premise. You’re given a shuffled deck of cards. Each card has a type of activity on the card and is a certain color based on the type of learning preference it targets. For example one card may say “You use music during breaks”. You go through the card and place all the ones you actively do in your classroom into one pile, and place the ones you don’t in the discard pile. At the end of the activity, you have a clearer picture of what learning preferences you target, and what preferences you don’t. And you get ideas for activities to do in the classroom.

I thought making a digital version of this would work well. The app would present each card to you and ask you if you do that activity. When you’re all done, the cards would be displayed in both piles.

Here’s where I need advice. How would you architect this in React? I assume each card would be a component. I would imagine that I’d have the cards in an array and would iterate through the array, displaying each card. When the card is selected, I’d push it into one of two other arrays, a “does” array and a “does not” array. At the end of the process I’d iterate through both arrays and render the components into one of the two “piles”.

But I’m unsure how to orchestrate all of this. Doing this with jQuery would be pretty simple. But I’d like to know how you React folks would tackle something like this. I'm not really looking for code though. Just some nudges in the right direction.

I'm also not looking to get free consulting from anyone. I won't be selling this app. I'll open source it.

you could start, as you mention, with the Card component. Define the potential properties and use PropTypes to enforce them. Then you can even define a Pile as another component.

next, you should think of the type of actions you can take on the cards and piles. These will be your flux actions. One might be MOVE_CARD, one might be ADD_TO_PILE. Each of these actions would trigger a function that produces the new state for that item. For example,

MOVE_CARD(cardID, status = does || doesnt) => { ...card, card.status }

this allows you to track your data changes in a single place, and return a new copy of state for every action.

Hopefully that gives you some ideas to get started. I recommend Redux as your flux implementation.

I think in Facebook's React docs, there is an image where they draw a UI (a todo list or something) and then use different colored boxes to break down the interface, could be something like

<TodoApp>
  <Input>
    <InputTextbox>
    <SubmitButton>
  </Input>
  <TodoList>
     <Todo1>
     <Todo2>
  </TodoList>
</TodoApp>

this is just conceptual, in the code you would just have TodoApp call Input, and the Input module would know about InputTextbox and SubmitButton...

Anyway React is still primarily a view layer, but it sounds like you are modelling your model layer - they can be separate. Maybe begin by drawing the UI - which actual components will be displayed at different times, and how can you compose them.

Then you figure out how to deal with the model/controller, whether using Redux or something else. In my experiment with React and Elixir, I actually pushed the model/controller to the Elixir server, so the React app just rendered a single state tree received through websockets, and actions just caused a message to be sent to the server, which resulted in an updated state tree being pushed out. This worked well because it was a shared interface (chat/brainstorming for a group). I'm working on turning this approach into a library.

If you didn't want to get into flux just yet and are just looking to understand the basics of props/state, you could also just keep the pile of cards as a simple array in a containing Pile or Game component's state, and pass a function down into each card which uses setState to update the state of the card stack in the parent.

But agreed on Redux, it's excellent. React-dnd might also be helpful depending on how fancy you're looking to get with draggable cards.

I did a quick read, so I might have misunderstood some parts :P I'll try to give you some hints:

First of all, the skelethon:

• not required, but useful: define a Container to store the components. you can use its state to store some shared infos
• define a component to represent a Deck. it will have some internal states:
  • is a generic deck, a "does" or "does not"?)
  • what cards are inside this deck
• define another component to represent the Card, along with its internal state (color, target, etc...)

The rest, is relatively easy in the sense that it depends by the actions you want to take and how to display them. from here, you have to decide where to put events/callbacks/elements based on the workflow/ui.

I was a bit generic, I could help you in depth with more details :-) meanwhile, hope it was helpful :-)

@houshuang I am really interested in how you used sockets with Elixir - that's a whole other problem I'm lookign to understand - the socket responses just render or update your React components? I'm pretty comfortable with React components themselves, but now I'm just interested in something to bind them together and manage the actions. I suppose a server-side part could fill that role - but it seems overkill for this. However, not for something else. Might you have a repository or a blog post I could look at to understand how the socket stuff orchestrates the React components?

Thank you so much for taking the time to answer.

one thing I'd urge you to do in any case: Make your components have as little state as possible. For example, a Card should only take properties. If needed, state can be handled in a container.

@tgriesser thanks for taking the time to answer. I was actually thinking about that approach but I wasn't sure if it was appropriate. :)

@VinSpee yea. I would imagine that only the Piles would have state - I would push a card onto the state for that pile, causing it to render all the new cards that get added.