Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #37569 > unrolled thread

Weather App - one more round?

Back to article view | Back to comp.lang.javascript

Contents

  Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-16 21:15 -0700
    Re: Weather App - one more round? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-17 21:05 -0700
      Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-17 21:31 -0700
        Re: Weather App - one more round? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-18 12:42 -0700
      Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-18 00:16 -0700
        Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-18 00:44 -0700
          Re: Weather App - one more round? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-10-18 13:23 +0200
            Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-18 13:43 -0700
              Re: Weather App - one more round? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-10-18 23:42 +0200
          Re: Weather App - one more round? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-18 12:36 -0700
        Re: Weather App - one more round? dr.j.r.stockton@gmail.com - 2019-10-18 02:25 -0700
          Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-18 13:14 -0700
      Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-18 13:35 -0700
        Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-20 21:10 -0700
          Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-20 21:20 -0700
          Re: Weather App - one more round? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-21 04:21 -0700
            Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-21 15:21 -0700
              Re: Weather App - one more round? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-21 16:36 -0700
                Re: Weather App - one more round? Julio Di Egidio <julio@diegidio.name> - 2019-10-26 04:20 -0700
                  Re: Weather App - one more round? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-26 07:45 -0700
                    Re: Weather App - one more round? luserdroog <luser.droog@gmail.com> - 2019-10-26 11:06 -0700
                      Re: Weather App - one more round? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-26 16:23 -0700
                        Re: Weather App - one more round? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-10-27 11:05 +0100
                          Re: Weather App - one more round? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-27 10:12 -0700
                            Re: Weather App - one more round? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-10-28 00:44 +0100
                    Re: Weather App - one more round? Julio Di Egidio <julio@diegidio.name> - 2019-10-28 05:50 -0700
                      Re: Weather App - one more round? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-28 06:40 -0700
                        Re: Weather App - one more round? Julio Di Egidio <julio@diegidio.name> - 2019-10-28 07:00 -0700

Page 1 of 2  [1] 2  Next page →

#37569 — Weather App - one more round?

The weather app has been redesigned and rebuilt according to the 
latest advice from Michael Haufe. I think it's much nicer now.
There is more information presented with less traffic. Unless you
search for a new location, changing options just does a redisplay
without a new network request.

It does give me a feeling of being more complicated now, but it
supports a more complicated behavior so maybe that's as it should be.

This version of the Weather App presents a Detail view on the left
and a table of Forecast data on the right. Normally the Detail pane
displays the current Weather data, but moving the mouse over any
line of the Forecast will cause the Detail pane to display the data
projected for that point of time.

The project is divided into: index.html, style.css, mvc.js, weather.js,
and app.js. Where 'weather.js' defines several application specific
classes which 'app.js' imports and uses. The 'app.js' file becomes
more like a "patch bay" rigging up the custom objects into a useful
arrangement.

Comments welcome. Hopefully, I'm erring less and less.

https://luser-dr00g.github.io/weather5/
https://github.com/luser-dr00g/luser-dr00g.github.io/tree/c1b5f5f2d666f7c76304d6be3c16b3eaf7d90287

[toc] | [next] | [standalone]

#37575

On Wednesday, October 16, 2019 at 11:15:25 PM UTC-5, luserdroog wrote:
> The weather app has been redesigned and rebuilt according to the 
> latest advice from Michael Haufe. I think it's much nicer now.
> There is more information presented with less traffic. Unless you
> search for a new location, changing options just does a redisplay
> without a new network request.
> 
> It does give me a feeling of being more complicated now, but it
> supports a more complicated behavior so maybe that's as it should be.
> 
> This version of the Weather App presents a Detail view on the left
> and a table of Forecast data on the right. Normally the Detail pane
> displays the current Weather data, but moving the mouse over any
> line of the Forecast will cause the Detail pane to display the data
> projected for that point of time.
> 
> The project is divided into: index.html, style.css, mvc.js, weather.js,
> and app.js. Where 'weather.js' defines several application specific
> classes which 'app.js' imports and uses. The 'app.js' file becomes
> more like a "patch bay" rigging up the custom objects into a useful
> arrangement.
> 
> Comments welcome. Hopefully, I'm erring less and less.
> 
> https://luser-dr00g.github.io/weather5/
> https://github.com/luser-dr00g/luser-dr00g.github.io/tree/c1b5f5f2d666f7c76304d6be3c16b3eaf7d90287


I think before I'd want to comment on your JavaScript, I'd want you to fix your HTML and CSS:

https://html5.validator.nu/?doc=https%3A%2F%2Fluser-dr00g.github.io%2Fweather5%2F


For CSS, you need to treat it as seriously as you would your code. Luckily there is a methodology for this that aligns well with OOP. This is also a bit dated (2011?) but still relevant IMO as a starting point:

http://smacss.com/book/

After that let's circle back and align your HTML+CSS components with your View classes. Some other things might fall out of this by accident, for example: you should be able to get to a point where you don't need to rely on method names as an index for something.

Also, if you're concerned about complexity, there is an objective measure of this that you can use (Cyclomatic Complexity). The JSHint tool provides this as one of its checks:

https://jshint.com/

Basically lower is better. A score of 10 or above is bad.


Finally, you'll notice that trying to manage all of this at once in development is getting pretty... detailed. Are you using an IDE such as VSCode?

[toc] | [prev] | [next] | [standalone]

#37576

On Thursday, October 17, 2019 at 11:05:14 PM UTC-5, Michael Haufe (TNO) wrote:

> Finally, you'll notice that trying to manage all of this at once in development is getting pretty... detailed. Are you using an IDE such as VSCode?

I'm using emacs, evil mode. Recent convert after using vim for a long time.
It has some kind of syntax highlighting and automatic indentation turned on. 
I usually run full screen and split down the middle into a left pane and
right pane. But once or twice in the latest rewrite, I split one of the 
panes into top and bottom so I could peek at 3 different files at once.

I'm previewing with Firefox on a win10 laptop running a
cygwin/apache/mysql/php stack. After uploading I'm checking with Chrome
on a win 8 laptop. And an android phone.

[toc] | [prev] | [next] | [standalone]

#37582

On Thursday, October 17, 2019 at 11:31:30 PM UTC-5, luserdroog wrote:
> On Thursday, October 17, 2019 at 11:05:14 PM UTC-5, Michael Haufe (TNO) wrote:
> 
> > Finally, you'll notice that trying to manage all of this at once in development is getting pretty... detailed. Are you using an IDE such as VSCode?
> 
> I'm using emacs, evil mode. Recent convert after using vim for a long time.
> It has some kind of syntax highlighting and automatic indentation turned on. 

I guess flycheck is what you want then?

https://www.flycheck.org/en/latest/languages.html

VSCode has better language awareness, and supports emacs keybindings, but practically probably doesn't matter much. I know there is fervor around IDE choices.

[toc] | [prev] | [next] | [standalone]

#37577

On Thursday, October 17, 2019 at 11:05:14 PM UTC-5, Michael Haufe (TNO) wrote:
> Also, if you're concerned about complexity, there is an objective measure of this that you can use (Cyclomatic Complexity). The JSHint tool provides this as one of its checks:
> 
> https://jshint.com/
> 
> Basically lower is better. A score of 10 or above is bad.
> 

I checked my complexity, and I think I'm mostly ok. Median is 2 on
all files. Max is 18, but I quibble that it's a matter of interpretation.
It seems to be considering ?: as an enclosing construct, even if I'm
clever enough to use it without parens. So when I chain 18 of them in
a row: poof, complexity is 18.

Is there a better way to write this function? 

class DetailView extends View {
  //...
  compassPoint( d ){
    return (d<11.25 || d>=348.75)? 'N' :
      (d>=11.25 && d<33.75)? 'NNE' :
      (d>=33.75 && d<56.25)? 'NE' :
      (d>=56.25 && d<78.75)? 'ENE' :
      (d>=78.75 && d<101.25)? 'E' :
      (d>=101.25 && d<123.75)? 'ESE' :
      (d>=123.75 && d<146.25)? 'SE' :
      (d>=146.25 && d<168.75)? 'SSE' :
      (d>=168.75 && d<191.25)? 'S' :
      (d>=191.25 && d<213.75)? 'SSW' :
      (d>=213.75 && d<236.25)? 'SW' :
      (d>=236.25 && d<258.75)? 'WSW' :
      (d>=258.75 && d<281.25)? 'W' :
      (d>=281.25 && d<303.75)? 'WNW' :
      (d>=303.75 && d<326.25)? 'NW' :
      (d>=326.25 && d<348.75)? 'NNW' : 'error';
  }
}

[toc] | [prev] | [next] | [standalone]

#37578

On Friday, October 18, 2019 at 2:16:40 AM UTC-5, luserdroog wrote:
> On Thursday, October 17, 2019 at 11:05:14 PM UTC-5, Michael Haufe (TNO) wrote:
> > Also, if you're concerned about complexity, there is an objective measure of this that you can use (Cyclomatic Complexity). The JSHint tool provides this as one of its checks:
> > 
> > https://jshint.com/
> > 
> > Basically lower is better. A score of 10 or above is bad.
> > 
> 
> I checked my complexity, and I think I'm mostly ok. Median is 2 on
> all files. Max is 18, but I quibble that it's a matter of interpretation.
> It seems to be considering ?: as an enclosing construct, even if I'm
> clever enough to use it without parens. So when I chain 18 of them in
> a row: poof, complexity is 18.
> 
> Is there a better way to write this function? 
> 

Better after a little googling:

  compassPoint( d ){
    let t = ['N','NNE','NE','ENE',
	     'E','ESE','SE','SSE',
	     'S','SSW','SW','WSW',
	     'W','WNW','NW','NNW','N'];
    return t[ Math.round( d / 22.5 ) ];
  }

That gets my max down to 5.

[toc] | [prev] | [next] | [standalone]

#37580

luserdroog <luser.droog@gmail.com> wrote on 18 Oct 2019 in 
comp.lang.javascript:

> compassPoint( d ){
>     let t = ['N','NNE','NE','ENE',
>           'E','ESE','SE','SSE',
>           'S','SSW','SW','WSW',
>           'W','WNW','NW','NNW','N'];
>     return t[ Math.round( d / 22.5 ) ];
>   }

const compassPoint = ( d ) => {
	return [
		'N','NNE','NE','ENE',
		'E','ESE','SE','SSE',
		'S','SSW','SW','WSW',
		'W','WNW','NW','NNW','N'
	][ 
		Math.round(d % 360 * 4 / 90) 
	];
};
 



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#37585

On Friday, October 18, 2019 at 6:23:27 AM UTC-5, Evertjan. wrote:
> luserdroog <luser.droog@gmail.com> wrote on 18 Oct 2019 in 
> comp.lang.javascript:
> 
> > compassPoint( d ){
> >     let t = ['N','NNE','NE','ENE',
> >           'E','ESE','SE','SSE',
> >           'S','SSW','SW','WSW',
> >           'W','WNW','NW','NNW','N'];
> >     return t[ Math.round( d / 22.5 ) ];
> >   }
> 
> const compassPoint = ( d ) => {
> 	return [
> 		'N','NNE','NE','ENE',
> 		'E','ESE','SE','SSE',
> 		'S','SSW','SW','WSW',
> 		'W','WNW','NW','NNW','N'
> 	][ 
> 		Math.round(d % 360 * 4 / 90) 
> 	];
> };
>  

Thanks, that is nicer. I was a little hesitant to push the syntax
that far (shocking as that may be). I've modified your idea further
by arranging the strings in a way that (to my eye) makes the logic
of the letters more apparent. At least for the 3 letter codes, the
first letter is the same as the nearest cardinal point.

class CompassPoint {
  constructor( deg ){ this.deg = deg; }
  toString(){
    return [     'N','NNE',
      'NE','ENE','E','ESE',
      'SE','SSE','S','SSW',
      'SW','WSW','W','WNW',
      'NW','NNW'
    ][ Math.floor( (this.deg+11.25) / 22.5 ) % 16 ];
  }
}

[toc] | [prev] | [next] | [standalone]

#37586

luserdroog <luser.droog@gmail.com> wrote on 18 Oct 2019 in 
comp.lang.javascript:

> return [     'N','NNE',
>       'NE','ENE','E','ESE',
>       'SE','SSE','S','SSW',
>       'SW','WSW','W','WNW',
>       'NW','NNW'
>     ][ Math.floor( (this.deg+11.25) / 22.5 ) % 16 ];

You could use XOR 0 to force the integer part.

With positive small values this is the same as Math.floor(),
but probably[!] faster.

return [
      'N','NNE',
      'NE','ENE','E','ESE',
      'SE','SSE','S','SSW',
      'SW','WSW','W','WNW',
      'NW','NNW'
    ][ (this.deg + 11.25) / 22.5 % 16 ^ 0 ];


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#37581

On Friday, October 18, 2019 at 2:44:25 AM UTC-5, luserdroog wrote:
> 
> Better after a little googling:
> 
>   compassPoint( d ){
>     let t = ['N','NNE','NE','ENE',
> 	     'E','ESE','SE','SSE',
> 	     'S','SSW','SW','WSW',
> 	     'W','WNW','NW','NNW','N'];
>     return t[ Math.round( d / 22.5 ) ];
>   }

Besides your optimization, if you look at the context of usage you'll
notice that the compassPoint method does not reference 'this' 
(the DetailView), and does not look to be an operation of it.

Therefore it should probably be its own entity:

```javascript
class CompassPoint {
  constructor(deg) {
    this.deg = deg;
  }
  toString(){
    let t = ['N','NNE','NE','ENE',
             'E','ESE','SE','SSE',
             'S','SSW','SW','WSW',
             'W','WNW','NW','NNW','N'];
    return t[ Math.round( d / 22.5 ) ];
  }
}
```

Then in onUpdate your usage would be:

```javascript
...
  this.find('.detail_wind_dir').textContent =
    data.wind.deg ? `${new CompassPoint(data.wind.deg)}` : '';
...
```

As a trick, because I used `toString` as the method name, 
it will be called implicitly when you use it in a string
context like I did above.

This may seem to be a small step backwards at first, but now
you're able to extend the concept of CompassPoint with 
additional operations as well as validation if desired:

```javascript
class CompassPoint {
  constructor(deg) {
    this.deg = deg % 360
  }
  ...
 }
```

This also allows you to change what it means to be a compassPoint.
You could reduce and increase the number of directions without
having to modify any other code that relies on its methods

> That gets my max down to 5.

Cool. Just don't worry about the total number as that will
obviously increase as you add more functionality and features.

[toc] | [prev] | [next] | [standalone]

#37579

On Friday, 18 October 2019 08:16:40 UTC+1, luserdroog  wrote:

> Is there a better way to write this function? 
> 
> class DetailView extends View {
>   //...
>   compassPoint( d ){
>     return (d<11.25 || d>=348.75)? 'N' :
>       (d>=11.25 && d<33.75)? 'NNE' :
>       (d>=33.75 && d<56.25)? 'NE' :
>       (d>=56.25 && d<78.75)? 'ENE' :
>       (d>=78.75 && d<101.25)? 'E' :
>       (d>=101.25 && d<123.75)? 'ESE' :
>       (d>=123.75 && d<146.25)? 'SE' :
>       (d>=146.25 && d<168.75)? 'SSE' :
>       (d>=168.75 && d<191.25)? 'S' :
>       (d>=191.25 && d<213.75)? 'SSW' :
>       (d>=213.75 && d<236.25)? 'SW' :
>       (d>=236.25 && d<258.75)? 'WSW' :
>       (d>=258.75 && d<281.25)? 'W' :
>       (d>=281.25 && d<303.75)? 'WNW' :
>       (d>=303.75 && d<326.25)? 'NW' :
>       (d>=326.25 && d<348.75)? 'NNW' : 'error';
>   }
> }

Yes.  Roughly, take (d+11.25) % 22.5, take the integer part, use that to index an array of strings.  You probably need to have 17 strings, with 'N' as first and last.  When testing, use 'n' as first, in case it helps you to see what is happening. That advice should be nearly right throughout; but not necessarily bug-free.

AFAIK, %22.5 should be perfectly OK - if worried, multiply d by 2 & use %45.  You can easily extend that for the full compass, with quarter-points.

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#37583

On Friday, October 18, 2019 at 4:25:46 AM UTC-5, dr.j.r...@gmail.com wrote:
> On Friday, 18 October 2019 08:16:40 UTC+1, luserdroog  wrote:
> 
> > Is there a better way to write this function? 
> > 
> > class DetailView extends View {
> >   //...
> >   compassPoint( d ){
> >     return (d<11.25 || d>=348.75)? 'N' :
> >       (d>=11.25 && d<33.75)? 'NNE' :
> >       (d>=33.75 && d<56.25)? 'NE' :
> >       (d>=56.25 && d<78.75)? 'ENE' :
> >       (d>=78.75 && d<101.25)? 'E' :
> >       (d>=101.25 && d<123.75)? 'ESE' :
> >       (d>=123.75 && d<146.25)? 'SE' :
> >       (d>=146.25 && d<168.75)? 'SSE' :
> >       (d>=168.75 && d<191.25)? 'S' :
> >       (d>=191.25 && d<213.75)? 'SSW' :
> >       (d>=213.75 && d<236.25)? 'SW' :
> >       (d>=236.25 && d<258.75)? 'WSW' :
> >       (d>=258.75 && d<281.25)? 'W' :
> >       (d>=281.25 && d<303.75)? 'WNW' :
> >       (d>=303.75 && d<326.25)? 'NW' :
> >       (d>=326.25 && d<348.75)? 'NNW' : 'error';
> >   }
> > }
> 
> Yes.  Roughly, take (d+11.25) % 22.5, take the integer part, use that to index an array of strings.  You probably need to have 17 strings, with 'N' as first and last.  When testing, use 'n' as first, in case it helps you to see what is happening. That advice should be nearly right throughout; but not necessarily bug-free.
> 

Thanks. I missed that 11.25 term in my rewrite elsethread. 

> AFAIK, %22.5 should be perfectly OK - if worried, multiply d by 2 & use %45.  You can easily extend that for the full compass, with quarter-points.
> 

Very interesting. I suppose that does make sense considering JavaScript's 
philosophy of trying to return a useful result from operations that are
considered errors in other languages. But it's still surprising to me that
you can use floating point operands with %. In my other languages I often
have to find or concoct an 'fmod' function when I need this.

[toc] | [prev] | [next] | [standalone]

#37584

On Thursday, October 17, 2019 at 11:05:14 PM UTC-5, Michael Haufe (TNO) wrote:
> On Wednesday, October 16, 2019 at 11:15:25 PM UTC-5, luserdroog wrote:
> > 
> > Comments welcome. Hopefully, I'm erring less and less.
> > 
> > https://luser-dr00g.github.io/weather5/
> > https://github.com/luser-dr00g/luser-dr00g.github.io/tree/c1b5f5f2d666f7c76304d6be3c16b3eaf7d90287
> 
> 
> I think before I'd want to comment on your JavaScript, I'd want you to fix your HTML and CSS:
> 
> https://html5.validator.nu/?doc=https%3A%2F%2Fluser-dr00g.github.io%2Fweather5%2F
> 

Thanks. I've cleaned up the html. I can't decide whether to preload all
the possible image icons since I have 41 img's standing by. OTOH if they're
not needed, that's extra traffic.

> For CSS, you need to treat it as seriously as you would your code. Luckily there is a methodology for this that aligns well with OOP. This is also a bit dated (2011?) but still relevant IMO as a starting point:
> 
> http://smacss.com/book/
> 
> After that let's circle back and align your HTML+CSS components with your View classes. Some other things might fall out of this by accident, for example: you should be able to get to a point where you don't need to rely on method names as an index for something.
> 

This seems to be a bigger job. I'm digging in to that book and I'll check back
when I've applied it. Thanks again.

[toc] | [prev] | [next] | [standalone]

#37587

On Friday, October 18, 2019 at 3:35:38 PM UTC-5, luserdroog wrote:
> On Thursday, October 17, 2019 at 11:05:14 PM UTC-5, Michael Haufe (TNO) wrote:
> > On Wednesday, October 16, 2019 at 11:15:25 PM UTC-5, luserdroog wrote:
> > > 
> > > Comments welcome. Hopefully, I'm erring less and less.
> > > 
> > > https://luser-dr00g.github.io/weather5/
> > > https://github.com/luser-dr00g/luser-dr00g.github.io/tree/c1b5f5f2d666f7c76304d6be3c16b3eaf7d90287
> > [snip]
> > For CSS, you need to treat it as seriously as you would your code. Luckily there is a methodology for this that aligns well with OOP. This is also a bit dated (2011?) but still relevant IMO as a starting point:
> > 
> > http://smacss.com/book/
> > 
> > After that let's circle back and align your HTML+CSS components with your View classes. Some other things might fall out of this by accident, for example: you should be able to get to a point where you don't need to rely on method names as an index for something.
> > 
> 
> This seems to be a bigger job. I'm digging in to that book and I'll check back
> when I've applied it. Thanks again.

I've read most of that book now. And I've done some intermediate steps
to beef up my tooling. I wrapped the html in php so I could generate 
all the repetitive stuff with a simple loop. And I've installed and set 
it up to compile my css with sass. Need to sleep on it and then turn to the
actual task of reigning in the css and wrangling the html.

On the other front, I've read up about flycheck. Seems like a very useful
thing to have. Probably install it soon.

[toc] | [prev] | [next] | [standalone]

#37588

On Sunday, October 20, 2019 at 11:10:47 PM UTC-5, luserdroog wrote:

> actual task of [reining] in the css and wrangling the html.

I noticed this typo a split second after posting. sigh.

[toc] | [prev] | [next] | [standalone]

#37593

On Sunday, October 20, 2019 at 11:10:47 PM UTC-5, luserdroog wrote:

> [...] And I've done some intermediate steps
> to beef up my tooling. I wrapped the html in php so I could generate 
> all the repetitive stuff with a simple loop. 

That's concerning. You shouldn't have to. After your next iteration we can take a look.

[toc] | [prev] | [next] | [standalone]

#37596

On Monday, October 21, 2019 at 6:21:51 AM UTC-5, Michael Haufe (TNO) wrote:
> On Sunday, October 20, 2019 at 11:10:47 PM UTC-5, luserdroog wrote:
> 
> > [...] And I've done some intermediate steps
> > to beef up my tooling. I wrapped the html in php so I could generate 
> > all the repetitive stuff with a simple loop. 
> 
> That's concerning. You shouldn't have to. After your next iteration we can take a look.

Ok. I think I'm ready. I reordered the css to match the smacss schema and
replaced id selectors and base selectors with classes where appropriate.

Here's a table of my models, views, and related html classes.

_location  locationView  .controls>#loc.panel

unit       unitView      .controls>#unit.panel

days       daysView      .controls>#days.panel
           chartdays     .report>.chart>.chart_0...chart_4

weather    report        .report
           details       .report>.detail

forecast   chart         .report>.chart

Thinking about the goal of not looking up functions by class name,
I'm guessing that the locationView, unitView, and daysView should
add their own click handlers to their respective .panel elements?

Browse current commit:
https://github.com/luser-dr00g/luser-dr00g.github.io/tree/a22c5d769253e4b7b8b293f9af2661303c5e6c96/weather5
Zip:
https://github.com/luser-dr00g/luser-dr00g.github.io/archive/a22c5d769253e4b7b8b293f9af2661303c5e6c96.zip
Live:
https://luser-dr00g.github.io/weather5/

[toc] | [prev] | [next] | [standalone]

#37597

On Monday, October 21, 2019 at 5:22:00 PM UTC-5, luserdroog wrote:
> On Monday, October 21, 2019 at 6:21:51 AM UTC-5, Michael Haufe (TNO) wrote:
> > On Sunday, October 20, 2019 at 11:10:47 PM UTC-5, luserdroog wrote:
> > 
> > > [...] And I've done some intermediate steps
> > > to beef up my tooling. I wrapped the html in php so I could generate 
> > > all the repetitive stuff with a simple loop. 
> > 
> > That's concerning. You shouldn't have to. After your next iteration we can take a look.
> 
> Ok. I think I'm ready. I reordered the css to match the smacss schema and
> replaced id selectors and base selectors with classes where appropriate.
> 
> Here's a table of my models, views, and related html classes.
> 
> _location  locationView  .controls>#loc.panel
> 
> unit       unitView      .controls>#unit.panel
> 
> days       daysView      .controls>#days.panel
>            chartdays     .report>.chart>.chart_0...chart_4
> 
> weather    report        .report
>            details       .report>.detail
> 
> forecast   chart         .report>.chart
> 
> Thinking about the goal of not looking up functions by class name,
> I'm guessing that the locationView, unitView, and daysView should
> add their own click handlers to their respective .panel elements?
> 
> Browse current commit:
> https://github.com/luser-dr00g/luser-dr00g.github.io/tree/a22c5d769253e4b7b8b293f9af2661303c5e6c96/weather5
> Zip:
> https://github.com/luser-dr00g/luser-dr00g.github.io/archive/a22c5d769253e4b7b8b293f9af2661303c5e6c96.zip
> Live:
> https://luser-dr00g.github.io/weather5/

Let's try to avoid non-standard approaches (SASS). CSS already supports variables:

<https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties>

Additionally, 'div' is meaningless:

```css
.panel > div:hover {...}
```

What does it represent on the page? 

Self contained 'components' are better represented by the <article/> tag as well:

<https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article>


You should also be aware of and consider the applicability of the element.hidden property:

<https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/hidden>


An yes, I agree. The views could manage their own click handlers, and possibly expose a more restricted and relevant set to their associated controllers.

The next architecture I'd like to introduce at this stage since you've been exposed to and maybe burned by MVC is called HMVC where the 'H' stands for Hierarchical. Dusting off another old link from 2000:

<https://web.archive.org/web/20000815074120/http://www.javaworld.com/javaworld/jw-07-2000/jw-0721-hmvc.html>


This one is in Java, but I suspect that won't stop you from getting the gist of it and how it's an improvement on what you've discovered thus far, and maybe partially reinvented.

The associated code for that article is here:

<https://web.archive.org/web/20051031045244/http://www.javaworld.com/jw-07-2000/hmvc/jw-0721-hmvc.zip>

The main idea is you'll see each Controller initialize its child triad as needed, but you can have each controller do the work itself if you want hide away the dirty details. Unlike the Java version, in the web you can already create your own custom events if the ones provided are insufficient or if you want to get creative:

<https://developer.mozilla.org/en-US/docs/Web/API/Event/Event>

Finally, I think you can consider at this point not having the html elements in the page at all, but construct them at the same time that you construct your View:

```javascript
class MyPanel extends View {
  constructor(model){
    super(model)
    this._element = document.creatElement('article')
    this._element.classList.add('panel')
  }
}
```

The container controller can then do the work of appending your view to it's own view. Your top level Controller is now the application and it's View is the documentElement or the body element.

HTH, but I suspect you might be getting a bit disenchanted as every door you open turns into another hall of doors.

[toc] | [prev] | [next] | [standalone]

#37623

On Tuesday, 22 October 2019 01:36:08 UTC+2, Michael Haufe (TNO)  wrote:

> HTH, but I suspect you might be getting a bit disenchanted as every door you
> open turns into another hall of doors.

Which brings us back to lesson #1: do not code for the patterns...

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#37624

On Saturday, October 26, 2019 at 6:20:11 AM UTC-5, Julio Di Egidio wrote:
> On Tuesday, 22 October 2019 01:36:08 UTC+2, Michael Haufe (TNO)  wrote:
> 
> > HTH, but I suspect you might be getting a bit disenchanted as every door you
> > open turns into another hall of doors.
> 
> Which brings us back to lesson #1: do not code for the patterns...
> 
> HTH,
> 
> Julio

I would only partially agree with this statement unless you can expand on it:

I'd agree that one shouldn't approach uninformed development by throwing patterns at it. "I don't know what I'm doing, so I'll use the Factory pattern here".

Though in contrast it has long been known that when you apply a language in a domain it is not optimized for design patterns and idioms emerge [1]. Is that an argument against General Purpose programming languages I wonder, or just evidence of missing orthogonal constructs [2]?

To bring this back home to the current thread, the fact that MVC was chosen as an architectural pattern wasn't a "bad" choice, just less optimal then its successors (such as HMVC) or competitors (such as PAC). With the height of the learning curve, I like to think of it as a lie that helps tell the truth (and at the pace the OP wants to go).


[1] <http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures>
[2] <https://en.wikipedia.org/wiki/Orthogonality#Computer_science>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web