Firstly, I'm not entirely sure what is the @@ prefix in the actions which most third-party packages I've installed in my React/Redux app mean -- if they mean "private", then the answer to my question is obvious. I see them in the Redux devtools extension for Chrome.
In case it's just a scoping convention @@<package>/<action>, then I have a concrete question regarding actions in redux-form package. Actions are, apparently, not documented, so I'm not sure if I can safely use them in my reducers without worrying for breaking changes.
For more context in case my approach is completely wrong (still figuring out patterns): I want to remove the register form and present a success message after successful completion. redux-form dispatches an action of type @@redux-form/SET_SUBMIT_SUCCEEDED, with meta.form telling me that it was a form I named register. So I'd use it in my RegisterPage reducer to set a boolean isSuccess and use that to change the view.
If they are not explicitly documented I would consider them private and not use them directly. Even though it's not stated officially anywhere, the @@ prefix often indicates private actions which shouldn't be handled by other reducer code. I think it originated from the @@redux/INIT_{random string} action (discussion about the naming can be found in this github thread):
In the new docs (#140) we should clarify that any actions prefixed with @@ are not meant to be handled. For example, you should never try to handle @@INIT.
In the redux code itself the privateness is also explicitly stated:
/**
* These are private action types reserved by Redux.
* For any unknown actions, you must return the current state.
* If the current state is undefined, you must return the initial state.
* Do not reference these action types directly in your code.
*/
For your specific problem: you could provide a onSubmitSuccess function to the HOC and dispatch your own action to update your own reducer or you could directly depend on the redux form state and get this boolean flag via the hasSubmitSucceeded selector. Personally I think the second option is the better one because it doesn't introduce redundant state in your store - redux form already stores the information whether a form was submitted successfully, doing so on your own in another sub-reducer could lead to the two boolean values diverging unintentionally.