-
Notifications
You must be signed in to change notification settings - Fork 80
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
DraftJS Kills <Accounts.ui.LoginForm /> - I don’t know why! #96
Comments
Okay, figured it out (I think) std:accounts-ui just doesn't maintain any kind of state. If react decides to re-render the form for any reason it totally kills Weirdness. Anyways, here's the code to test it to see what I'm talking about:
The code above always returns to the state passed to it in the props.
This is even worse! because something re-renders the page, the whole form just vanishes for no reason. So - This issue is closed, I'm going to investigate further and find out if there is a better way of maintaining state. If not, I'm going to post a feature request issue. Thanks so much for your hard work! |
Okay - no, something is really wrong here. Because if you force the state to be in sign-up mode the form doesn't respond to show that you're logged in when you're logged in. If somebody could please take a look at this and explain, I would really appreciate it. |
Thanks to Sean (arist0tl3) and his comment and his fork It's interesting what he did there. Basically, I was calling
and Sean tried taking
Created a
Then called the two from a parent
I'm not actually sure why this works... but it does. It seams to me as though The million dollar question:Is this a bug, or part of the intended design? The two-million dollar question:Is there come explanation of why this is the way it is that I should know? Like, why is it normal that To sweeten the deal a little bit - I've created a StackOverflow question to this extent. - Now it's worth points! :) |
Is this still an issue, @JeremyIglehart? |
I'm really not sure what is happening here. When I click on the "DraftJS" contentEditable - the
<Accounts.ui.LoginForm />
instantly disappears. I haven't the foggiest idea why.Demo:
To see the bug in its current state:
Go to: http://draftjsmeteor.autoschematic.com/
To duplicate the problem in your own development environment:
settings-development.json
file (you can leave it blank)npm start
The main question:
Does anyone know why DraftJS kills the
<Accounts.ui.LoginForm />
?After looking into this problem for two days now, I suspect the problem is hiding somewhere in how
<Accounts.ui.LoginForm />
is doing something - perhaps in their STATES API? I'm really confused here. Any help would really be appreciated.Problems I've ruled out:
Session Variable
problem. DraftJS doesn't use them - in fact, there are no Session Variables being used at all right now as far as I can detect (using Meteor Toys)<Accounts.ui.LoginForm />
component I have placed a regular vanilla<p>
tag and it is left alone.It doesn't seem to me this problem has anything to do with Meteor, or React specifically.
Where I'm looking now to solve this:
accounts-ui
is rendering just fine - after clicking in the DraftJS contentEditable area, however, something inside this component breaks.Issues Tracking this Bug:
I've created three issues to try and track this down:
Once I find a solution I'll update all of the issues, forums and questions I've posted everywhere.
The text was updated successfully, but these errors were encountered: