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

Docs update #37

Open
innoflash opened this issue Apr 24, 2020 · 3 comments
Open

Docs update #37

innoflash opened this issue Apr 24, 2020 · 3 comments

Comments

@innoflash
Copy link
Contributor

So i dont know what you guys think but i was suggesting that we promote more the use of the config file or the trait.

I have seen that so far we are requiring like 9 more entries on the this package on the .env file and if we think of something new it means thats one more line.

The whole database uses only 5-6 lines on the .env and a whole load of config data.

I dont know but what do you think?

@edgrosvenor
Copy link
Contributor

Sounds good. I've added a draft PR where we build out the README a little better.

@innoflash
Copy link
Contributor Author

Awesome, also how about renaming the trait to something like CanLoginWithoutPassword or CanPasswordlessLogin or even something better.

So far the trait name is the same as the Facade name which i am suspecting is a recipe for disaster.

To keep the current implementations working we could create a trait with the right name and make that trait use the current such that users can use them interchangeably until when we finally depricate the prevous

@edgrosvenor
Copy link
Contributor

I'm less concerned about the names being the same than I am about introducing a breaking change. A decent IDE will make it pretty clear when you're trying to use the wrong thing. I'm open to being convinced but I don't see how the two having the same name would have any negative consequences other than maybe having to alias one of them if you're using both in the same class and I can't figure out why anyone would ever want to do that.

So if we ever get to the point where a total rewrite is called for or some other good reason comes up to release a v2.0 we will definitely rename one or the other. But my thinking at the moment is that it's not a good enough reason to bump major versions right now.

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

No branches or pull requests

2 participants