had the same problems with exporting actions and types as part of the duck as you end up with cyclic dependencies. so the best solution, for me, was to simply import the actions/types where they were needed directly, not as an import from the duck. not sure about the reducer reference you were mentioning
In this case I send the match params from the server side react-router matching to each of the
serverFetch function which is related to a certain page. This would be at line 15 from this snippet — https://gist.github.com/alexnm/baa5fa6a73d434d60a643c4a840efd9a#file-server-js. The the
serverFetch function will use that match object to obtain url parameters and send them to an API for example
not really related to this article, but I don’t think that redux and the context api are on the same level to be interchangeable. I think they address different needs
That’s an interesting take. Do you have a repo with the expanded example? I would be curious to have a closer look at that.
I would like to feature other projects with new ways of doing this architecture on github on this repo: https://github.com/alexnm/re-ducks
Good point. But what exactly is shared logic? can you give me a few example of features/concepts you would put there? I see no problem in creating a duck that handles some common data/state. Plus if you are careful and don’t over use this, you can easily import actions and types from one duck to another if you need to handle, for example, one action type in multiple reducers.
Just to clarify, only the initial request calls are made by the server. When you login on the page, you just submit a form / do a regular post to the actual API, not to the code that does the server rendering. Does this make sense?
Thank you for the feedback, I’m glad my effort pays off. Regarding your question, I would advise against using the same codebase for both your server rendered app and your actual backend. API calls within the same infrastructure/cluster should have no significant overhead so you can easily split up your app
Next is a great framework, I can’t recommended it enough. But it comes with more than just SSR. It has automatic routing based on filesystem structure, it has automatic code splitting and so on. It always depends on your scenario.
Not really. Actions are functions, they are no accessible from outside the duck. They are encapsulated by operations. Types are just identifiers. Since any reducer can respond to any action, it needs those types to identify the correct action.
If index.js acts like an interface for a folder (it exports other modules), then you rarely have to edit it. If index.js stands for a component, like you mentioned (CustomerTable) then searching for the folder will give you exactly that file first. Trust me, I’m using it with no problem on a medium-large size project.