Agile Web Development with Rails 6 Chapter 12. Task G
--
Currently reading and working through AWDR6 by Sam Ruby, David Bryant Copeland, and Dave Thomas. I have run into a couple issues and worked through them. I couldn’t find some solutions so decided to make a work log here for anyone else that might be working through this book.
The Pragmatic Programmers are amazing enough to have hosted this book on Medium as well. If you are interested in following along, or practicing yourself follow the link .
Task G: Check Out!
Hold on ter ya britches. We enter the land of DSLs. I mean rails is the mega conglomerate of dsls which is honestly really annoying and I understand why folx are both excited to reduce that in Rails 7, and are picking other frameworks that all use the same language. I like being good at what I do and there is nothing like sweating over a problem when it is syntax in a dsl error, and likely a dsl that you will not use in a month and probably forget.
Summary
- We created a form to capture details for the order and linked it to a new order model.
- We added validation and used helper methods to display errors to the user.
- We provided a feed so the administrator can monitor incoming orders.
Playtime
[✓] — Get HTML — and JSON- formatted views working for who_bought requests. Experiment with including the order information in the JSON view by rendering @product.to_json(include: :order). Do the same thing for XML using ActiveModel::Serializers::Xml.
Issue: Working with rendering options here, I did not jump into RSS feeds, Atom Feeds, XML, or JSON Jbuilder as much as I typically would with a project because they are all very niche. I practiced learning what I needed to know to get the task done. Something I am trying to get better at.
Investigation: This is where we start working with all the rendering options which was fun. It is the same information being rendered but you can now access it with json, atom, and html. It was a fun exercise.
Solution: Below you will find the directory with all of my different views.
[✓] — What happens if you click the Checkout button in the sidebar while the checkout screen is already displayed? Can you find a way to disable the button in this circumstance?
Issue: no real issues with this one.
Investigation: more resources on helpers.
Solution: I decided to use the current_page? helper to conditionally render the checkout button.
[✓] — The list of possible payment types is currently stored as a constant in the Order class. Can you move this list into a database table? Can you still make validation work for the field?
Issue: I don’t know if this is the best way to do it.
Investigation: I didn’t really know what to look up for this, I used intuition and just played around with it in the console until it worked.
Solution: I ran this migration on the database. It worked for it, the validations I changed along with the select options.
If you have a better migration idea, lemme know. This is a 1am thought so pretty low. I do like having the enum on the model to hash the response from the database. It seems like it is micro-optimizing but it was fun. Plus the select was one source of truth which I enjoyed.
I suppose you could do something like Order.uniq.pluck(:pay_type) but then you would have to have the database with each order initialized.
I am in a Ruby book club. If you are interested in joining direct message me, hit me up on twitter, reach out!
