Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a default _navigation_footer.html.erb #1450

Merged

Conversation

jrochkind
Copy link
Contributor

@jrochkind jrochkind commented Sep 16, 2016

Prior to this PR, backend/app/views/spree/admin/shared/_navigation_footer.html.erb
is an empty file, save for a comment.

solidus_auth_devise overrides the partial to provide basic 'you are logged in as',
'logout' etc functionality in the admin sidebar.

However, there's nothing really devise-specific about this functionality.
We can easily implement it just in terms of ordinary spree, and the
methods that any auth solution is expected to provide, like spree_logout_path

This will make it easier on custom auth, no reason to have to figure out what to do
here on your own to get equiv func to the solidus_auth_devise standard when we
can provide a default. Custom auth could still override this partial if wanted/needed, but
this default should ordinarily suffice.

solidus_auth_devise can keep overriding it, we don't hurt it any by providing a default
implementation, instead of just a blank file, for it to replace.

The actual implementation here was straightforward -- figuring out how to test it
was a colossal pain. It's kind of kludgey in a couple ways, but I tried nearly many
approaches before arriving at what's here as least evil I could find.

@@ -0,0 +1,3 @@
Spree::Core::Engine.routes.draw do
root to: lambda {|env| [200, {'Content-Type' => 'text/plain'}, ["Home page"]]}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Space between { and | missing.
Unused block argument - env. If it's necessary, use _ or _env as an argument name to indicate that it won't be used. Also consider using a proc without arguments instead of a lambda if you want it to accept any arguments but don't care about them.
Space inside { missing.
Operator => should be surrounded by a single space.
Space inside } missing.
Space missing inside }.

@@ -0,0 +1,3 @@
Spree::Core::Engine.routes.draw do
root to: lambda {|env| [200, {'Content-Type' => 'text/plain'}, ["Home page"]]}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Space between { and | missing.
Unused block argument - env. If it's necessary, use _ or _env as an argument name to indicate that it won't be used. Also consider using a proc without arguments instead of a lambda if you want it to accept any arguments but don't care about them.
Space inside { missing.
Operator => should be surrounded by a single space.
Space inside } missing.
Space missing inside }.

soldius_auth_devise currently overrides with it's own.
That's fine, but we can provide a default that should work
fine for most custom auth solutions (rails g spree:custom_user)
@jrochkind jrochkind force-pushed the default_backend_navigation_footer branch from 48dc6a7 to 83e9a50 Compare September 16, 2016 20:43
end
end
end
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't you try writing a view spec. Those are usually easy to write, very fast, and you can mock the hell out of it. I don't think that you need to test rails routing, and that spree_logout_path and such exist for real. It's a great overdo for such a view functionality.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay if the consensus is a view spec is correct and sufficient, I can do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

huh, under the new github system it looks like hound comments don't go away even if you fix em and force push? THAT's annoying.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mtomov I'll change to a view spec, that does make sense, backend previously had no view specs at all, which is maybe what discouraged me from using it before. Hopefully that'll deal with the test failure from unreliable spec too.

@mtomov
Copy link
Contributor

mtomov commented Sep 19, 2016

Yeah, hopefully it won't require you to go through leaps and bounds to test
this.

On Mon, Sep 19, 2016 at 2:07 PM, Jonathan Rochkind <[email protected]

wrote:

@jrochkind commented on this pull request.

In backend/spec/features/admin/auth_nav_spec.rb
#1450:

  •  reloader.reload!
    
  • end
  • after do
  •  @load_extra_routes = false
    
  •  Rails.application.routes_reloader.reload!
    
  • end
  • it "has a back to store link" do
  •  visit spree.admin_path
    
  •  within("#login-nav") do
    
  •    page.find_link Spree.t(:back_to_store), href: "/"
    
  •  end
    
  • end
  • end
    +end

@mtomov https://github.com/mtomov I'll change to a view spec, that does
make sense, backend previously had no view specs at all, which is maybe
what discouraged me from using it before. Hopefully that'll deal with the
test failure from unreliable spec too.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1450, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABk0JhEsPL4X_NR7YEpz440c1zy5YHHsks5qrokMgaJpZM4J_Uad
.

@jrochkind
Copy link
Contributor Author

@mtomov switched to view spec. Github's recent changes seem to mean that rubocop's warnings that no longer apply to any code in this branch stay there forever, as does our comments on source code lines no longer in this branch. Kind of annoying.

Copy link
Contributor

@mtomov mtomov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the view specs very much, very easy to understand and follow 👍

require 'spec_helper'

describe "spree/admin/shared/_navigation_footer", type: :view do
let(:user) { create(:admin_user) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically, even Spree::User.new should do fine here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it possible for an ordinary Spree::User to be viewing the admin backend at all? I guess it doesn't matter for a view test though.

I believe it does need to be a saved user (with an id) (or something mocked similarly), so generating a path to the admin user edit page for the user will work.

I am wary of mocking too much, because of other spree/solidus tests that mock so much they become unreliable.

I think it's prob okay the way it is, most 'realistic' test scenario, but if you require a different approach here just let me know. I suppose it can be create(:user), or a built non-saved user with it's id mocked out so a path can still be generated.... that latter one is not attractive to me for several reasons though.

Copy link
Contributor

@mtomov mtomov Jan 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spree.user_class.new can be used. Of course, as you see fit. Just in terms of speed, not persisting data where possible I think is preferable.

And yeah .. making the start with the first view spec is indeed the toughest, so great on doing that! Might encourage others to follow suite as they are easy to write, and quick to run.

I don't have anything else, maybe the others can have their say.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spree.user_class.new is quicker than factorygirl? I guess it can be build instead of create if it doesn't need to persist, but I feel like it oughta be an admin user?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, new is faster. FactoryGirl.build is marginally slower, as it will persist associated objects. For now though I think it's fine, let's deal with this in a subsequent PR. The answer to the conundrum would probably FactoryGirl.build_stubbed.

@jrochkind
Copy link
Contributor Author

I don't understand the CI failure, and think it is unrelated to this PR?

expect(rendered).to have_link(Spree.t(:back_to_store), href: "/")
end
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra empty line detected at block body end.

@jrochkind
Copy link
Contributor Author

ping? @mtomov? Anything else I can do?

@mtomov
Copy link
Contributor

mtomov commented Mar 23, 2017

Looks good!

<!-- solidus_auth_devise inserts a login_nav here.
<ul id="login-nav" class="admin-login-nav"></ul>
<!-- solidus_auth_devise replaces this partial with it's own login_nav.
But we provide a defaut implementation below that should work with
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo "defaut".

Copy link
Contributor

@mamhoff mamhoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm for this despite the typo and the DB hit in the view spec.

require 'spec_helper'

describe "spree/admin/shared/_navigation_footer", type: :view do
let(:user) { create(:admin_user) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, new is faster. FactoryGirl.build is marginally slower, as it will persist associated objects. For now though I think it's fine, let's deal with this in a subsequent PR. The answer to the conundrum would probably FactoryGirl.build_stubbed.

Copy link
Member

@tvdeyen tvdeyen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@tvdeyen tvdeyen merged commit f91a0fd into solidusio:master Oct 4, 2017
gregdaynes pushed a commit to gregdaynes/solidus that referenced this pull request Oct 4, 2017
Caught in a PR review (solidusio#1450), and merged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants