sandwich_app

Created with CodeSandbox

Notes on Development

• Total Project Time: ~20 hrs
• Wireframes: invisionApp
• Github: sandwich app
• CodeSandbox: sandwich app
• Tech: React with JavaScript
• Testing: Manual - plan to add Jest testing later
• Commenting: JSDoc

Assumptions

1. This app is designed for customer-facing workers managing a register, not building orders.
2. This app is part of a larger ecosystem where components designed here should be extensible to other applications.
3. The data.json file represents the response (or a collection of responses) from an API call.
4. This is built for a computer screen or tablet - not a phone.
5. There will be more than just 3 menu items in the future.
6. This app will be making API requests to a database for the menu, inventory, and order history.
7. There are no tax, tips, or service charges included.

Extensibility

I tried to build this app to be as extensible so that it could fit into an existing app or be expanded out easily. Here's a few highlights on how I've achieved this:

1. There are classes to manage orders, menu items, and inventory.
2. There are fetch placeholders for API calls in the Inventory class and in the Menu Component.
3. Components are self-contained and reusable.

Interesting Challenge: Deep Cloning vs Shallow Cloning Instances

Turns out, this is a lot harder than I originally thought. After some research, I discovered that there are packages that help with this, but as a work around I added a stand-in _.clone() method to my classes that returned the instance's attributes, and made all the attributes optional in the constructor. That way, I could "Deep Clone" and object by calling new ObjectConstructor(objectToClone.clone())

Stretch Features

In addition to fulfilling the requirements of the challenge, there are a few stretch features I implemented:

1. A tracker for Active Orders
2. A tracker for Average Completion Time on an order
3. The ability to edit orders
4. The ability to remove an item from an order once it has been added
5. The ability to cancel orders
6. A toggle to hide/show completed orders
7. A timer on orders that shows how long the order has been active. This timer turns red if the order has been active for more than 20 min
8. The completion time of a completed order
9. Images to the menu items, rendered on the menu and on the order list

Planned Features

There are a few stretch goals I imagined in my wireframes that I have not yet had the chance to implement.

1. A working Search feature to search for an order
2. The ability to reopen and/or copy a previously closed order
3. A tab and scrolling feature to accomodate an extended menu
4. Add-ons or additional options for a given sandwich
5. The "New Order" button as an order box

Improvements/Weaknesses

Here are some highlights of some notable shortcomings of the implementation. Some of these are due to time constraints, while others are due to limitations set forth by the parameters of the project. Notably, sometimes shipping is more important than addressing all of these - tech debt is both an expectation for agility and a necessity for a young company/project.

1. UI is very basic - now that the features are in this could do for another design pass. However, given the app doesn't have much of an identity beyond this challenge, it is hard to frame. Further UI improvements likely come with the establishment of a restaurant name and brand, etc. These improvements seem beyond the scope of this challenge.
2. Further optimizations for small screens - Around 600px, some of the UI breaks down. Though my design and use of flexboxes and grids allows for fairly decent responsiveness, there would need to be some changes for a mobile applications such as collapsing menus, more responsive images and data entry forms, etc. As an example, in the "Create/Edit Order" modal, I would likely remove Sandwich names and descriptions from the selection boxes and use only pictures at a certain breakpoint.
3. Confirmation modals - Users would get quite frustrated if they accidently cancelled or completed an order. Confirmation modals for these types of actions would improve the UX.
4. Styling of the scroll-bars and other built-in elements.
5. Custom built form components instead of HTML forms and bandaid css.
6. Automatic timer updates instead of updating with a rerender. It should leverage a timeout or interval closure to update the time every minute.
7. Some props are passed down several layers of children. This could be improved with reducers.