part III -> specs (should be good for the hard core rails crowd)
part V -> adding more features
part VI -> devise
part VII -> marketing your app so that you make $1M overnight
part XI -> find true love
wow all this because you use hyperstack!
cool
I am figuring a post a week is about right
was goign to update the Devise tutorial I wrote last year
@catmando re Devise, what I have been wondering about is if there is a way to keep the Admin JS completely separate from the User JS app. In the past I have done:
Rails.application.routes.draw do
authenticate :member do
mount Hyperstack::Engine => '/hyperstack'
get '/(*other)', to: 'hyperstack#main_frame'
end
endSo, a not-logged in user does not even get to the Hyperstack API or the JS app (they stay in HTML pages with normal Rails routes). I have been thinking that depending on the user (admin/normal) they get a different main component which has its own client side routing - just thinking...
So I am thinking that the whole Admin section can be in one JS package and the rest of the app in another and rails view templates will only bring in the admin section if the user is Admin
This would get past the problem of Admin type code being a part of the client code.
not 100% sure but you would just do something like this:
get '/admin/(*other)', to: 'hyperstack#admin'
get '/(*other)', to: 'hyperstack#app'
(cause rails runs the first route it hits)
catprint actually has a bunch of smaller SPAs
the possible problem with a static login page, is just user experience.
the possible problem with a static login page, is just user experience.
Same style sheet and bits of JS niceness will overcome that
I know the easiest way to get into devise (for example) is take that route (no pun intended) but it certainly can be done to get things wired up to use hyperstack ControllerOps (or even tweak a rails controller to deliver some JS) in the long run its going to give a better experience.
Same style sheet and bits of JS niceness will overcome that
of course, but you still have this reload going on.
which is unnecessary
from hyperstacks standpoint all that happens when you login, is that new channels are created.
Of course if you are adapting an existing site then keep you current login strategy, at least until you have more important pieces working.
IMHO of course
we lived with a pretty gross strategy for years at Catprint
@catmando call scheduling app could be a good example app number of angles
- Non trivial app w/an actual use - that's always the problem with example apps, their either too simple to give a feel of the power, or too much to digest
- dogfooding gives the best apps - since we should use it for our calls in the future, we'll be more investing in making it good, and refining over time
- We should document it via blog and video as we're building. Blogs are good for the "follow the book part", video should highlight cool dev things like hot reloading in a situation where the data setup is significant, so a hot reload doesn't require you to re setup
- and of course, an open source repo, coz working code is always the best documentation
- who knows maybe if successful, it could become a real product
@barriehadfield I think a call to action as well as a blog posts section is good, we'll headline the latest hot post, and reference all the other collected posts
@catmando re: the Ruby is fast enough post, I think that's good reason to keep going with Rails, I presently think that's the best bet for adoption - a "batteries included on front and back end" solution which would lean on everything that Rails brings to the table