view() seems to merge SAM's model(), state() and representation() steps into one place
Yes, that's generally my issue with all the samples with see regardless of the framework. It's really not helpful, by now we should know better.
Have you seen the samples from the sam-pattern library? It's really easy to decompose your app logic into simple functions. For the clock example, it looks like it's able to subscribe to system events which is nice:
subscriptions: state => interval(Tick, { delay: 1000 }),But I would really prefer if the Tick function did not mutate the application state directly.
In SAM events are external, but it is recommended to connect events to actions. You could consider passing the event itself as a proposal, but I would consider a bad/poor coupling. Events are emitted outside the SAM loop and should always be bound to actions.
I configured once to make it work with netlify deployment. It use webpack so it can be a configuration hell if you need specific behaviors.
The doc is vey helpful thought .
I was looking for a quick tool to make modern website without classic CMS.
I have just finished to design my web site and plan to integrate it next month. So I can't say more on the final usage.
The doc is vey helpful thought .
I was looking for a quick tool to make modern website without classic CMS.
I have just finished to design my web site and plan to integrate it next month. So I can't say more on the final usage.
So I'm trying to understand how SAM would compose in a scenario where there is a Server and Client, and a parent-level state representation that describes say 3 actions, which must each be completed once by the client. The client application only presents 1 of these to the user at a time, according to its own strategy (e.g. pages in an application form that it guides the user through).
But here the client-side view can't be functionally determined by the server state alone, as it requires local control state which incorporates the strategy. Is there an established way in which this would compose?
But here the client-side view can't be functionally determined by the server state alone, as it requires local control state which incorporates the strategy. Is there an established way in which this would compose?
Actually it's way simpler than I thought
Thanks
@petebarnett yes, parent/child composition is very easy with SAM. The child can either invoke an intent of the parent or directly submit a proposal to the parent's model. When you wire the parent SAM loop within a child's action, you can even use the parent's state representation as a proposal to the child's model. In essence, all combinations are possible and can be very easily wired as needed.
The benefits of the full decoupling between action and model always keep on showing up, that's why I am so adamant about it.
The benefits of the full decoupling between action and model always keep on showing up, that's why I am so adamant about it.
.dom project: https://github.com/wavesoft/dot-dom
The library should never exceed the 512 bytes in size. The goal is not to have yet another template engine, but to have as many features as possible in 512 bytes. If a new feature is needed, an other must be sacraficed or the scope must be reduced.
This reminds me of something “Stop Using Else in Your Programs” by Joey Colon https://link.medium.com/Qne6G7wYU0
It's ok if I am wrong, but I remain on my position that this is the wrong formalism, and that formalism doesn't scale in scope. I spent 15+ years of my career building model driven software (working with some of the best people in that field and starting with the mother of all MDS, Interface Builder which was written in the late 80s by a Frenchman) and I came to the conclusion this is the wrong way to write software.
Interface Builder was a piece of code that seem alien back in the late 80s, it is something that had never been seen before. I count as my friend, Jack Greenfield, one of the authors of the first Object-Relational Mapper (Enterprise Object Framework).
All that doesn't mean I am right, but I have been around enough to understand the limitations of MDSE (Model Driven Software Engineering), combined that with the limitations of FSM/State Charts and it's hard for me to believe that a couple of diagrams prove anything.
@formido that's scaling in scope or lack there of https://mobile.twitter.com/ryanflorence/status/1189728090575921152
Vue suffers the sale rearchitecture fever as react https://vueschool.io/articles/vuejs-tutorials/exciting-new-features-in-vue-3/
@metapgmr_twitter Hi, I'm again working with Angular to build an Ionic (4) app for a client of mine, and I'm wondering if the
sam-pattern library can be used, or it's too much work (as a side note, after being exposed to functional libs like react and the likes, I see every bit of Angular code like a hacky trick...)
The sam-pattern library is quite easy to integrate with Angular (and I assume ionic, though I never worked with it, I created a sample here: https://github.com/jdubray/sam-samples/tree/master/todomvc-app-angular
now Ionic (like NativeScript) is framework agnostic (yes, you can build with vanilla js too..), but the Angular integration is the most mature, at least for now
it' just a collection of web components and supporting utilities/services
@metapgmr_twitter re lit-html, really liked the video overall, although I am not sure I love the way they use events in general, and I haven't decided how much I like their dependency injection (feels very unstructured, but not too different from react providers in the end - I liked the way angular used to do it back in the days, but it's been a while)
@riccardoferretti I'll be able to tell after the first POCs, and after my first couple custom Web Components (with StencilJS). I want to test the overall experience, from extending ionic components with custom ones, integrating custom ones with ionic, and then applying state management with SAM. Ionic 4 is a totally different experience from 3 under the hood, and I need to primarily target the web with a PWAs, but keeping native packaging as an option. So, for example, I'm trying to create custom ionic input components that provide a custom web on-screen-keyboard when used on a desktop browser (for kiosk touch PCs) and instead use the native keyboard on mobile
PS: re Flutter, is very promising and working with Dart is a pleasure, but the web support is kinda early stage now, and in general it suffers the same problems as React Native.. that is, if you want something more complex than the widgets it gives you (and you can't find a third party one), you'll have to write native code anyway (for every platform you target). The advantage of hybrid is that you always use html/css/js for everything. As per the performance, well, if you're not building a super complex game, or some heavy graphic based app, you'll never notice a difference (maybe some quirks, but with some experience/tricks you can work around them)
in addition to ionic 4, take a look to NativeScript (with Angular), the latest releases are very mature and promising, for example the Code Sharing functionality makes possible to write a single project targeting both mobile (real native) and web deployments: https://docs.nativescript.org/angular/code-sharing/intro
writing UI plugins for NS is a bit easier than with other libs (like RN) because they try to keep most of the code in TypeScript and not in the native code (if any is necessary)
for example, take a look at this: https://docs.nativescript.org/angular/plugins/ui-plugin-custom#platform-specific-code
here you can see some TypeScript code that wraps native button controls (android and ios), by using platform specific APIs directly in TS code.. it's kinda magic
@riccardoferretti one part that I felt was incorrect semantics is to connect events to routes. Clearly routes are idempotent actions, they put your application state in the same state (defined by the route) regardless of past history. IMHO, a route is the result of a step, and the view should not know about routes. Of course this argument is highly contentious and I maybe wrong, but I would prefer having the view know as little as possible and simply emit events (with data) that are wired to intents and ultimately to actions. Of course you could say since the view was constructed at the previous step, it's ok because the corresponding route was injected anyways, but to a certain degree I feel that's incorrect and routes should not mix with the view.
WRT your comment, I believe that's inherent to HTML, it's not purely functional (especially for progress bars and async wheels), I'd say it's better to just accept it and hack it, while you keep everything else purely functional. We'll simply never get to purity until HTML fixes it. It's better to focus on making everything else as pure as you can, ultimately people will notice how much better it would be and someone will eventually fix it. It might take 10 years to do so (I am sure that's the minimum time) but that's the only way forward I can see. Trying to say, "oh and our programming model deals with that case too" is the wrong approach, it's better to call it for what it is exactly then people will finally get it and say, "that sucks" there is gotta be a better way"