This is correct. I think you listed the primary use cases that each interface serves, but I would say ports goes beyond just data. I can provide a few examples of how we use both.
Our Elm application is embedded into several pages of a much older and larger CakePHP application (CakePHP is a full stack framework that is similar Django or Ruby on Rails in that it handles both front and back end). We use *Flags* to... - Set information about the current user's permission group, to show or hide certain view elements (the back end of course verifies this as well, so there's no way a user can receive or modify data they are not authorized to access) - Set the initialization mode of the application, allowing us to reuse certain view components of the Elm application in different pages but with different options enabled (e.g. a full screen mode and a windowed mode that gets embedded in a modal) - *Possibly* set the initial state of the model (currently the Elm app fires several HTTP requests to the back end API to download the application data) We use *Ports* to.. - Make very specific DOM manipulations (things we cannot do in Elm such as add or remove styles to the document's html node) - Access to the browser's window API (e.g. window.localStorage) Hope that helps. On Monday, April 3, 2017 at 1:41:57 AM UTC-5, Richard Wood wrote: > > Sounds like some nautical adventure! > > When is it appropriate to bring in data through flags vs through using > ports. > At the moment I'm thinking: > > Flags: > * When needed immediately on initialisation > * When it won't change > > Ports: > * Dynamic data > * Data not available at the start > > Is another reason to use a flag to avoid a perhaps unnecessary maybe? This > came up when trying to have a time variable. I don't want a maybe time > variable as then I have to handle the maybe every time I use it. So I'm > thinking to pass the time in as a flag to begin with then keep it update > through ports. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
