I want to make a shopify theme using react.
You have a bunch of template files that have access to global server-side variables with liquid e.g. {{ product.title }}
. Think wordpress or any other theme-based system.
/theme
http://www.zhlwish.com/2012/07/23/rails-activesupport-concern/
# autoload concerns
module YourApp
class Application < Rails::Application
# config.autoload_paths += %W(
# #{config.root}/app/controllers/concerns/
# #{config.root}/app/models/concerns/
# )
users = User.arel_table | |
query = users.project(users[Arel.star]) |
#!/usr/bin/env ruby | |
# Checks for things that I often commit accidentally and bails out of the | |
# commit. To skip this pre-commit hook use `git commit --no-verify`. | |
checks = [ | |
/\bddescribe\b/, | |
/\biit\b/, | |
/\bxit\b/, | |
/binding.pry/, |
# Extended configuration for Thinking Sphinx can be stored in the | |
# config/thinking_sphinx.yml file within your application (this file was | |
# previously known as config/sphinx.yml in TS v1/v2). | |
# | |
# Many settings from Sphinx itself can be set here, and they'll flow through to | |
# the appropriate section of the generated configuration. However, some are | |
# used for Thinking Sphinx behaviour, and so those are documented here first. | |
# | |
# Configuration is grouped by environment, just like config/database.yml in a | |
# standard Rails application. |
=Navigating= | |
visit('/projects') | |
visit(post_comments_path(post)) | |
=Clicking links and buttons= | |
click_link('id-of-link') | |
click_link('Link Text') | |
click_button('Save') | |
click('Link Text') # Click either a link or a button | |
click('Button Value') |
In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.
After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.
But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.
And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?
In dark rooms, in hushed tones, we speak of colours.