initial pf-react-demo-app architecture #2
Conversation
|
Why Typescript instead of Flow/ES6? See further commentary in #1. |
There was a problem hiding this comment.
@priley86 thanks! - I had a quick look and it seems fine - only comment is about not adding the missing components to pf-react directly vs building them here (nav, empty state etc).
I'm in mixed feelings about saga personally - how was your experience using it here?
| title: string; | ||
| } | ||
|
|
||
| export const EmptyState: React.StatelessComponent<Props> = props => { |
There was a problem hiding this comment.
shouldn't this be in patternfly-react repo instead?
|
@ohadlevy agree that we should add any new UI components directly to pf-react. Temporarily, this can be used as source of determining what we should add in pf-react, then we can remove them from here and import directly. The goal is for this repo to visually showcase our components in a real application scenario. |
|
can we merge this PR and iterate some more in future PRs? |
|
@ohadlevy I was just reading a good thread on Redux vs MobX on Twitter. This is a pretty hot topic these days... I'm a pretty big fan of the Redux/Redux Saga approach for complex state interactions. Having reducers/sagas which can be easily be tested/reproduced in our unit tests and debugged (with time travel 😸 ) is a huge win for us devs handling complex async state. I remember not too long ago using libraries like async.js to handle a chain of asynchronous interactions, but Saga breaks this down into generators (using yield/await,etc). A much better approach... With that being said, I think Redux is likely overkill for most simple UI state which is 1:1 (or is not changing in real-time like a notification list). So the advice I would give is only writing reducers/actions/sagas etc. when you know the state model will be complex, otherwise we have libraries like MobX (simpler state manager), or just simple API classes/simple reducers/simple selectors. WDYT? |
priley86
force-pushed
the
architecture
branch
2 times, most recently
from
e872bd5 to
9947509
Compare
|
In an attempt to keep this demo app moving, I am going to merge this PR and reference these issues for future additions. There are also a number of outstanding issues in PF-React which are ready for us to tackle. Here are the ones I've identified that are specific this demo app: |
This PR creates initial PF React demo architecture referenced in #1
Read more about all of the tools used and setup in the README
Some outstanding things that I would love some help on here:
logoutmechanism which invalidates user login in localStoage).anyin several places which are probably unnecessarynode-less-chokidar(similar tonode-sass-chokidar. There is currently a bug preventing us from being able to truly watch several LESS files and still enable a single App.less file to compile (so for now, only App.less is truly watched). It would be ideal to watch all LESS and still compile a single App.less (similar to this)Navstyles built by React Bootstrap in the masthead.SecondaryNavin the VerticalNav and fully implement this pattern in React (instead of Jquery). This code is incomplete.tslintconfiguration. However, as long asprettier.singleQuoteis enabled in your IDE, it should be fine to use Prettier and avoid tslint errors. I expect these issues to be cleared up soon for full Prettier support w/ tslint, but until I am excludingtslint-config-prettier.patternfly-reactdistributions (so that custom type definition is not needed here)